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

[Jacob Appelbaum]

On 03/20/2012 09:08 PM, Nick Mathewson wrote:
> 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.
> 

We can provide packages for users or a spec file for their users as an
alternative, I guess? I think generally we're already doing this by
providing the Tor Browser but all users with system tors are going to be
left out...

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

Sure, it's just a simple matter of programming. ;-)

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

I think that's a lot of stuff to say - we'll probably want to keep track
of our various fingerprints somewhere - a bug or the wiki, perhaps?

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

Well, OK, I think I understand that. Sorta. I agree that it is a step in
the right direction but I do think it's a nightmare unless we have some
way to basically make tor perform uniformly without us tracking things.
Basically, we can impersonate a few browsers on the client side but the
relays limit our ability to impersonate properly. It seems like a lot of
stuff to keep track up, I already want a lookup table to know which
version of tor, which version of openssl, which platform, etc to know
what my handshake looks like and so on. It's not that complicated, it's
just complicated enough though...

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

Ok, I admit, I had no idea that the group parameters were sent in the
clear - I agree, just hacking up the cipher suites isn't actually useful
in that case. Argh!

All the best,
Jake