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@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@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
On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum jacob@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 Mathewson