[tor-dev] Proposal 198: Restore semantics of TLS ClientHello

[Nick Mathewson]

On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
[...]
> Ah ha. That sounds like a nightmare. Is there a bug report we can pile
> on to request that they don't create a headache for everyone in the future?

There is, but I don't currently see much point: their developers are
irritated, and know that other developers are irritated, and believe
that they can't take any actual action without word from their legal
department.

>>> It seems that our integration with
>>> platforms is really heading in a bad direction. I'd like to figure out
>>> how to not diverge entirely and if possible to fix or document the issues.
>>
>> I don't know what you mean by "diverge" here -- do you mean that
>> different platforms may advertise different ciphers based on their
>> version of OpenSSL or whether their legal department fears ECC?  If
>> so, then all non-Tor OpenSSL applications running on those hosts
>> already leak this information.
>
> I mean - Tor's cipher suite advertisement will be really wacky,
> basically on a platform by platform basis, version by version basis.
> What we expect to say about tor's fingerprint is less and less easy to
> say concisely, or perhaps it's easy but has a few variants? It seems
> like we'll have to track it more closely, perhaps by sniffing network
> traces on a per OS basis?

It should be fairly easy to notice what ciphers we are really
advertising, and warn when it isn't the list we want to advertise.

What we can expect to say about the fingerprint will be: "If you have
a default build of OpenSSL 1.0.0 or later, then you will look like
Firefox 8+ (modulo other issues not related to ciphersuites).  If you
have an ECC-disabled build of OpenSSL 1.0.0 or later, then you will
look like FF8+ with all the ECC turned off. (I am pretty sure that
Fedora does indeed turn off the ECC in the Firefox they ship.)
Otherwise, if you have a really weird OpenSSL build, or an older
version of OpenSSL, your fingerprint will be weird."

 [...]
> My thought was as follows - we have a
> pt_client{many-cipher-suites-support} that can be made to impersonate
> many browsers, it can try to connect to either relays which it can thus
> become Firefox without issue or to a bridge with this
> pt_server{many-cipher-suites-support} support and so it can pretend to
> be nearly anything. I probably should have made that suggestion more
> explicit.
>
> But yes, I agree, unless we can make the servers support the required
> ciphers, I think we're doomed. I didn't miss that, I was just trying to
> suggest a hack whereby we can impersonate IE as a pluggable transport.
>
> I've wondered for a while about cipher suites, specifically, why can't
> we just lie on the wire and then internally map ciphers as we like? For
> example - our client sends ECDHE but our server understands this is us
> trying as a client to impersonate IE and maps that to some other forward
> secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a
> TLS nightmare but, I guess it feels like we're heading there anyway...?

Actually, we are heading AWAY from the TLS nightmare. That's the point
of this proposal: to minimize our use of ClientHello ciphersuite
fakery, so that the TLS ciphersuite negotiation handshake can
eventually just work again.

The idea above wouldn't work in any straightforward way: It is easy to
tell a DHE handshake from an ECDHE handshake -- for example, by
looking at the group parameters, which are sent in the clear! -- so if
the server says that it picks one but then the server and the client
do another, that would be really easy to detect.

> (I'm sorry if this seems rambly, I've been pretty sick...)

Hope you feel better soon!

cheers,
-- 
Nick