Fwd: Re: xxx-draft-spec-for-TLS-normalization.txt

[Jacob Appelbaum]

-------- 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

[Not sure if I can post into the list, but I'll give it a go...]

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.

>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.

>The second stage init_tls_dh_param() should randomly generate a new prime on
>a regular basis; this is designed to make the prime difficult to outlaw or
>filter.

Unless there's evidence of a large deployed base that does this, I'd
avoid it,
since the use of fresh primes rather than the Oakley ones will make you
stick
out.

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).

Peter.