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 <[email protected]> wrote: > On 03/20/2012 08:14 PM, Nick Mathewson wrote: >> On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <[email protected]> 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
