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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Forgot to send this to tor-dev: ouch.  Sending now.

On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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.

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.

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.

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

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.

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

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.

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

cheers,

--
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev