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

[Nick Mathewson]

Jacob sent me this message in reply to my last; sending to tor-dev
with permission.

On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> On 03/20/2012 08:14 PM, Nick Mathewson wrote:
>> On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>>> On 03/20/2012 08:33 AM, Nick Mathewson wrote:
>>>> Filename: 198-restore-clienthello-semantics.txt
>>>> Title: Restore semantics of TLS ClientHello
>>>> Author: Nick Mathewson
>>>> Created: 19-Mar-2012
>>>> Status: Open
>>>>
>>>
>>> [ ... ]
>>>
>>>
>>>>   Currently, OpenSSL 1.0.0 (in its default configuration) supports every
>>>>   cipher that we would need in order to give the same list as Firefox
>>>>   versions 8 through 11 give in their default configuration, with the
>>>>   exception of the FIPS ciphersuite above.  Therefore, we will be able
>>>>   to fake the new ciphersuite list correctly in all of our bundles that
>>>>   include OpenSSL, and on every version of Unix that keeps up-to-date.
>>>>
>>>>   However, versions of Tor compiled to use older versions of OpenSSL, or
>>>>   versions of OpenSSL with some ciphersuites disabled, will no
>>>>   longer give the same ciphersuite lists as other versions of Tor.  On
>>>>   these platforms, Tor clients will no longer impersonate Firefox.
>>>>   Users who need to do so will have to download one of our bundles, or
>>>>   use a (non-system) OpenSSL.
>>>>
>>>
>>> What platforms have this issue?
>>
>> The ones that don't have OpenSSL 1.0.0, and the ones that turn off
>> some of the relevant ciphersuites in OpenSSL 1.0.0.
>
>
> Sure, I understand the pre-OpenSSL 1.0.0 issue - I mostly wondered what
> platforms don't support the relevant ciphersuites in their builds of
> OpenSSL 1.0.0. We should either 0) file bug reports 1) offer packages
> that fix the issue or 2) something else such as ignoring it and simply
> tracking the issues.
>
>>
>> With time, the number of platforms that don't ship 1.0.0 or later will
>> fall.  Furthermore, we can support them just fine with a TBB that
>> includes OpenSSL.
>>
>
> Sure. That makes sense. The main downside is that TBB is a UX nightmare.
> It works OK for browsing and basically everything else becomes ten times
> the nightmare.
>
>> To the best of my knowledge, Fedora is the only major OS that ships
>> OpenSSL and turns off any of the ciphersuites we care about, though
>> there could be more.  Last I heard, their legal department were
>> reviewing that decision.
>>
>
> 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?
>
>>> 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?
>>
>> But in any case, I think that the damage is self-healing (as people
>> upgrade to OpenSSL 1.0.0) and the alternative of being stuck on our
>> current ciphersuites forever is worse.
>>
>
> Ok. That I find pretty convincing.
>
>>>> Open questions:
>>>>
>>>>   Should the client drop connections if the server chooses a bad
>>>>   cipher, or a suite without forward secrecy?
>>>>
>>>
>>> I think so. Do we have any relays that do not currently support forward
>>> secrecy?
>>
>> No.
>>
>
> Ok.
>
>> The question is, what should a client do if the relay selects, say,
>> TLS_RSA_AES_128_CBC_SHA1 (ciphersuite name may not be exact).  If it
>> drops the connection immediately, that might be unusual behavior.
>> Some other behavior might be smarter: perhaps it should pause for a
>> while, then drop.  Or perhaps it should send a little junk data then
>> drop.  I'm not sure there, though.
>
> Ah. What does s_client do if that selected cipher is not supported? When
> in doubt, I often just punt and do what s_client does...
>
>>
>> [...]
>>>>   Can we do anything to eventually allow the IE7+[**] cipher list as
>>>>   well?  IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or
>>>>   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current
>>>>   Tor servers, which _only_ support those.  It looks like the only
>>>>   forward-secure ciphersuites that IE7+ *does* support are ECDHE ones,
>>>>   and DHE+DSS ones.  So if we want this flexibility, we could mandate
>>>>   server-side ECDHE, or somehow get DHE+DSS support (which would play
>>>>   havoc with our current certificate generation code IIUC), or say that
>>>>   it is sometimes acceptable to have a non-forward-secure link
>>>>   protocol[***].  None of these answers seems like a great one.  Is one
>>>>   best?  Are there other options?
>>>>
>>>
>>> This sounds like a job for pluggable transports!
>>>
>>> I think as long as the servers support as many ciphers as possible, we
>>> can make simple pluggable transports that setup the cipher suites we
>>> want to use - no?
>>
>> Pluggable transports feel out-of-scope for this proposal.  But even if
>> they are, I don't see how they answer my question: Because (as a
>> given!) current servers do not support any of the forward-secure
>> ciphers on the IE7 list, if we want to impersonate IE7 or later, we
>> will be doing something that current servers cannot support.  Whether
>> this impersonation is done somehow as a plugin, or in Tor, it would
>> still be something we needed to coordinate with the servers in
>> question.
>>
>
> 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...?
>
> (I'm sorry if this seems rambly, I've been pretty sick...)
>
> All the best,
> Jake