[liberationtech] Deconstructing the security risks narrative of Haystack

[Daniel Colascione]

Hi Jacob. Thanks for the reply.

On 9/17/10 3:08 PM, Jacob Appelbaum wrote:

> Additionally, I did sleep on it
> after I spoke with Austin on Friday and I gave him the benefit of the doubt.
> I slept on it and ignored it largely until Sunday when I found the
> network was still up.

And as I said, I had sent you a personal email on Sunday, moments after
I learned the network was still up, assuring you that it was down and it
would not be brought back online. If this message was insufficient to
restore the CRC to the status of acting in good faith, then please
acknowledge that fact explicitly --- for the benefit of other software
creators, if nothing else.

>> In the interest of conciliation, would you agree to retract your
>> statements at http://twitter.com/ioerror/status/24434623289 and
>> http://twitter.com/ioerror/status/24425326976 in the same forum that
>> you originally made them?
> 
> Of course, I did that days ago:
> https://twitter.com/ioerror/status/24459645359
> https://twitter.com/ioerror/status/24460806692

I appreciate your later, more thoughtful comments on the affair (and
especially your kind comments regarding me). They are greatly
appreciated, and go a long way toward eliminating some of the ire
stemming from the incident.

But specifically, I was hoping for a specific repudiation of the "bullet
in the back of your head" comment. It was clearly excessive, and does
have grisly and unfortunate implications.

> I think twitter isn't the best medium for nuanced thoughts.

I wholeheartedly agree.

> You know just as well as I do that the _threat_ for detection of Tor is
> a passive or active adversary of some kind in the network path or when
> visiting a server through Tor. Haystack is much worse than this because
> of the "test" components in the build used in the wild.

The test program was more traceable, yes. The behavior of the program
that you mention allowed for a different method of traceability, and
both were clearly unacceptable. But nevertheless, the vulnerability
under discussion is traceability. The noxious feature we're talking
about merely about makes traceability easier.

Also, I checked the Tor disclosure page at
http://www.torproject.org/download.html.en#Warning and did not find
anything on precisely this point. (That page is an excellent summary of
the other issues, by the way.)

May I suggest adding a sixth entry stating that using Tor without a
private bridge relay (and not something in bridgedb) may reveal the
use of Tor?

>> A is true, and it is what I referred to what I said earlier that you
>> were right about the test program. Once certain parameters are known,
>> a network operator can detect it. As I mentioned, this statement is
>> also true of most anti-censorship products, Tor included. The
>> connection the test program made to its server is scarcely worse than
>> the connection Tor makes to its public and well-known directory
>> servers*. The same method can detect both programs.
>
> Additionally, the 40,000 (perhaps more, perhaps less - real anonymity is
> hard) users of Tor in Iran are not high value human rights activists
> known to be contacting a server that is clearly run by a suspected spy
> in the United States.

It appears to be the case now, Austin's statements notwithstanding, that
these people were not the high-value linchpin people that we both believed.

As Danny mentioned in an email further downthread, what makes talking
about this issue immensely frustrating is that there is a large class of
statements that cannot be trusted and that cannot be verified. On more
than one occasion during this affair, I've discovered facts that I had
not known myself, and I suspect there are more. I imagine that there are
many things that will remain unknown forever, which is quite regrettable.

> As I understand it - you thought to your credit, that the server was
> only in WHOIS as the upstream ISP and not actually tied to Austin Heap.
> When you, Danny and Austin had the call about this, it sounded like *you
> didn't know* this fact and were totally flabbergasted upon discovery. Is
> this observation incorrect?

That is correct.

> While I am not a lawyer, absolutely no one on this list seems to be an
> Iranian legal scholar. I think that even in the absence of such an
> expert, I'm happy to disclaim my lack of credentials and still hold an
> opinion on the matter.

Fair enough. We're all entitled to our opinions (though not our own
facts, of course). I'm merely suggesting to defer judgment in this area
to those qualified to comment on the particular circumstances of the
country under discussion.

> [snip]

>> * While Tor can be configured to use non-public bridge relays, most
>>   users will start the client in its default configuration, then look
>>   for alternative options only after observing that they cannot access
>>   the sites they would like. By this time, anyone monitoring
>>   connections to the directory servers will have already noticed a
>>   circumvention attempt.
> 
> This is actually difficult to know because our statistics are not for
> private bridges, only public bridges in the bridgedb. This is an
> important point, we have designed our systems to not be entirely
> observable even by ourselves.

And looking forward instead of back for a moment (which is refreshing),
it does seems like an important feature for any anti-censorship tool to
have is the ability to switch to a "full manual" mode that bypasses any
automatic method of determining a network path to the outside world.
Tor's bridge relay feature qualifies. My only concern would be that a
malicious third party could spread misinformation that could try to
convince users to misconfigure their clients and make detection (or
worse) more likely. Can you think of any specific examples of this
possibility being a problem?

Regards,
Daniel Colascione

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20100918/c0361aca/attachment.asc>