[liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud

[Asa Rossoff]

I composed the following SOME TIME back! (must have been around the time of
the Freedom Hosting initial revalations)

  -- it was never sent, so here it is.
  I don't have the dates, but this reply should get threaded properly...
  My reply is "dated" in the sense that it was based on info at the time, of
which there is much more now.  I believe I intended to add to this message
before sending, likely to respond to more of Jacob's comments.


For posterity, here is my reply as drafted to Jacob Applebaum
(Sincerely,Asa):

Jacob Appelbaum:
> Asa Rossoff:
>> Jacob Appelbaum:
>>> Asa Rossoff:
...
> Thanks for your response!

Surely.  I hope it adds value.  The rights to privacy and security are
important to me, especially as they apply to all people.  Although I have
some technical know-how, I am new to Tor and don't know a lot about
cryptography.

...
>> TBB users are at special risk of being targeted for spying (according to
>> recent news reports), hacking/exploits (as is the case in this instance),
>> and this may be increasingly true in the future.
>> 
>
> Probably, yes. I think that is a fair assessment - though it applies to
> anyone who uses privacy, security and anonymity software, I think.

Yes, I would think so too.  I saw no evidence that indicated a specific
interest in Tor.  In particular in terms of monitoring/spying, encryption
can draw attention, and has often provoked blocking or dropping of
connections in certain regions.  I think China recently blocked all SSL
access to Wikipedia, for example.

The most pertinent reference re. encryption provoking spying or attention
might be "Exhibit B" from the NSA docs, in regards to collecting data on US
"persons":
http://www.theguardian.com/world/interactive/2013/jun/20/exhibit-b-nsa-proce
dures-document relaying FISA sec. 701/702 "minimization procedures".  I
haven't read Exhibit A which I believe is about communications that are
known to involve non-US "persons".

Ironically, most of what that document describes sound like "maximization
procedures" to me.  The general rule of thumb seems to be that
communications can be kept for 5 years (or more--a "sufficient duration").
A sufficient duration for enciphered data or data believed to contain
"secret meaning" is indefinite, though -- at least until the meaning is
clear they can keep enciphered or "secret meaning" data forever.

My references to the above document by section, paraphrased in brackets (not
so much for your personal benefit as much as for the record)---
Section:
5.(3)(a)    [Domestic Communications-retention conditions(believed to
contain technical data base information)(enciphered/secret meaning)]
6.(a)(1)(a) [Foreign Communications of or Concerning United States
Persons(Retention conditions)(necessary for maintenance of technical data
bases)(enciphered/secret meaning)].
7.          [if the communication is "of or concerning" non-US "people"
there are no special restrictions]
8.          [Foreign governments can be provided "unminimized" and/or
enciphered/coded data for assistance in analysis or deciphering with the
proviso that the foreign governments aren't allowed to retain, disseminate,
or do anything with the data except give it back to the US--yeah,
right--although the US may give some of it back to them under other
procedures].

Further, if they find anything incriminating in any way during their
analyses, they can keep/disseminate it without regard to most of the other
procedures outlined.

...
>> The point I was getting to is that several parrallel strategies come to
>> mind:
>> (1) It would not be a bad idea to post applicable Firefox-issued security
>> avisories to one of your lists
>
> Part of the issue - from my perspective - is that 'applicable' is a bit
> nebulous. Nearly every bug *might* turn into an anonymity destroying bug
> with some engineering effort.
>
>> (2) Even have an RSS feed of them available through the TBB, as well as
RSS
>> of TBB releases, and what security issues are covred including one
advised
>> by Firefox.  This could notify of stable, alpha and beta releases, so
>> everyone knows when security updates are available, possibly at the cost
of
>> stability.
>
> I like this idea - though I wonder how users would feel about it? Will
> they read it? Should it be our own RSS feed or an RSS feed of Mozilla's
> data?
>
>> (3) When you get an update mechanism going, for stability reasons, you
>> probably want it to automatically only update to stable or beta
releases[?].
>
> I tend to prefer 'secure' update over 'automatic' update.
>
>> However, you could have a parrallel release schedule to get these
upstream
>> patches out ASAP.   I realize labor is involved here; but if at all
>> possible, updating your last stable patch to work with the latest Firefox
>> release ASAP and releasing it as a stable/beta while continuuing
development
>> on a more major/feature-related update that will start as an alpha
release
>> when ready. (possibly backporting some TBB-only-security fixes only to
your
>> last patch when it makes sense).
>
> Sure, that seems reasonable.
>
>> 
>> Obviously, this is free software, and you must work ithin the constraints
of
>> your resources.  The frequent security updates would have the most
tangible
>> benefit for most users, but it would be a decent user service to notify
of
>> security issues that apply/could apply to the TBB as well.
>> 
>
> I think there is a balance here and I think adding more specific data to
> release notes is a reasonable improvement. I also think an RSS feed is a
> really good idea, thanks for that! I'll pass it on to those more
> involved with TBB releases these days and see what they think.
>
>> Thanks for your invaluable work.
>> 
>
> Thanks for your positive feedback!
>
> All the best,
> Jacob

All the best, too,
Asa