Forgot to send this to tor-dev: ouch. Sending now. On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob@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. 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