On 03/20/2012 09:08 PM, Nick Mathewson wrote:

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.

We can provide packages for users or a spec file for their users as an alternative, I guess? I think generally we're already doing this by providing the Tor Browser but all users with system tors are going to be left out...

...

...

...

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.

Sure, it's just a simple matter of programming. ;-)

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

I think that's a lot of stuff to say - we'll probably want to keep track of our various fingerprints somewhere - a bug or the wiki, perhaps?

[...]

...

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.

Well, OK, I think I understand that. Sorta. I agree that it is a step in the right direction but I do think it's a nightmare unless we have some way to basically make tor perform uniformly without us tracking things. Basically, we can impersonate a few browsers on the client side but the relays limit our ability to impersonate properly. It seems like a lot of stuff to keep track up, I already want a lookup table to know which version of tor, which version of openssl, which platform, etc to know what my handshake looks like and so on. It's not that complicated, it's just complicated enough though...

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.

Ok, I admit, I had no idea that the group parameters were sent in the clear - I agree, just hacking up the cipher suites isn't actually useful in that case. Argh! All the best, Jake