xxx-draft-spec-for-TLS-normalization.txt

[Nick Mathewson]

On Fri, Feb 11, 2011 at 1:40 AM, Jacob Appelbaum <jacob at 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 <pgut001 at cs.auckland.ac.nz>
> To: jacob at appelbaum.net,, or-dev at 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 <jacob at 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