On Fri, Feb 11, 2011 at 1:40 AM, Jacob Appelbaum <ja...@appelbaum.net> wrote:
>
>
> -------- Original Message --------
> Subject: Re: xxx-draft-spec-for-TLS-normalization.txt
> Date: Mon, 31 Jan 2011 23:33:25 +1300
> From: Peter Gutmann <pgut...@cs.auckland.ac.nz>
> To: ja...@appelbaum.net,, or-...@seul.org
Hi, Peter, and thanks for having a look at this!
> [Not sure if I can post into the list, but I'll give it a go...]
Looks like your address wasn't subscribed to the list. Roger just
added it to the list of addresses that are allowed to post.
> Jacob Appelbaum <ja...@appelbaum.net> writes:
>
>>This is a document that proposes improvements to problems with Tor's current
>>TLS (Transport Layer Security) certificates and handshake that will reduce the
>>distinguishability of Tor traffic from other encrypted traffic that uses TLS.
>>It also addresses some of the possible fingerprinting attacks possible against
>>the current Tor TLS protocol setup process.
>
> In this case why not make the Tor certs as close as possible to generic
> OpenSSL ones? In other words do a scan of HOWTOs and whatnot and use
> that as
> a ruleset to create a cert, making them indistinguishable from a zillion
> other
> certs flying around that someone threw together on an as-needed basis.
I think that's a fine idea. We'd want to mine the EFF "SSL
observatory" data to see which HOWTO approaches have significant
adoption.
>>We currently send a static Diffieâ??Hellman parameter, prime p (or â??prime p
>>outlawâ??) as specified in RFC2409 as part of the TLS Server Hello response.
>
> These are the universal-standard primes, I'd stick with these in order to
> blend in with the crowd.
Preliminary results suggest that there wasn't actually a crowd here:
the reason that we switched the browser DH paramaters in the most
recent releases is that the old (standard!) primes were in fact
blocked by at least one nation-level censor because we used them. It
seems that in practice, if we want to blend with a crowd, we need to
use the hardwired DH parameters from mod_ssl.
[...]
> As a general comment, if you're worried about filtering/fingerprinting I'd
> make the traffic as close as possible to OpenSSL, since half the SSL apps on
> the net end up using this and Tor would get lost in the noise.
>
> (Note, having implemented both SSH and SSL and interop-tested it against God
> knows what sort of implementations, you can pretty much always
> fingerprint SSH
> due to its incredible complexity and implementation bugs ("oh, it's
> doing X in
> packet Y, that's version 123 of XYZ") and probably fingerprint SSL in a
> large
> number of cases, so there's a limit to how far you can take this).
Right. Once challenge is "openssl as configured by whom for what?" I
think that just going with a default OpenSSL profile to begin with
will be fine for some while, though.
cheers,
--
Nick
