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,