commit 16115c77fb7f2ee764df3ebf8cc2360f4d8ce479 Author: Nick Mathewson <nickm@torproject.org> Date: Mon Mar 19 13:30:10 2012 -0400 Add proposal 198: Restore semantics of TLS ClientHello --- proposals/000-index.txt | 2 + proposals/198-restore-clienthello-semantics.txt | 160 +++++++++++++++++++++++ 2 files changed, 162 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index c5f7707..d553084 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -118,6 +118,7 @@ Proposals by number: 195 TLS certificate normalization for Tor 0.2.4.x [DRAFT] 196 Extended ORPort and TransportControlPort [OPEN] 197 Message-based Inter-Controller IPC Channel [OPEN] +198 Restore semantics of TLS ClientHello [OPEN] Proposals by status: @@ -156,6 +157,7 @@ Proposals by status: 194 Mnemonic .onion URLs 196 Extended ORPort and TransportControlPort [for 0.2.4.x] 197 Message-based Inter-Controller IPC Channel [for 0.2.4.x] + 198 Restore semantics of TLS ClientHello ACCEPTED: 117 IPv6 exits [for 0.2.3.x] 140 Provide diffs between consensuses diff --git a/proposals/198-restore-clienthello-semantics.txt b/proposals/198-restore-clienthello-semantics.txt new file mode 100644 index 0000000..a28a3c7 --- /dev/null +++ b/proposals/198-restore-clienthello-semantics.txt @@ -0,0 +1,160 @@ +Filename: 198-restore-clienthello-semantics.txt +Title: Restore semantics of TLS ClientHello +Author: Nick Mathewson +Created: 19-Mar-2012 +Status: Open + +Overview: + + Currently, all supported Tor versions try to imitate an older version + of Firefox when advertising ciphers in their TLS ClientHello. This + feature is intended to make it harder for a censor to distinguish a + Tor client from other TLS traffic. Unfortunately, it makes the + contents of the ClientHello unreliable: a server cannot conclude that + a cipher is really supported by a Tor client simply because it is + advertised in the ClientHello. + + This proposal suggests an approach for restoring sanity to our use of + ClientHello, so that we still avoid ciphersuite-based fingerprinting, + but allow nodes to negotiate better ciphersuites than they are + allowed to negotiate today. + +Background reading: + + Section 2 of tor-spec.txt 2 describes our current baroque link + negotiation scheme. Proposals 176 and 184 describe more information + about how it got that way. + + Bug 4744 is a big part of the motivation for this proposal: we want + to allow Tors to advertise even more ciphers, some of which we would + actually prefer to the ones we are using now. + + What you need to know about the TLS handshake is that the client + sends a list of all the ciphersuites that it supports in its + ClientHello message, and then the server chooses one and tells the + client which one it picked. + +Motivation and constraints: + + We'd like to use some of the ECDHE TLS ciphersuites, since they allow + us to get better forward-secrecy at lower cost than our current + DH-1024 usage. But right now, we can't ever use them, since Tor will + advertise them whether or not it has a version of OpenSSL that + supports them. + + (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL + before 1.0.0e or so had some security issues with them.) + + We cannot have the rule be "Tors must only advertise ciphersuites + that they can use", since current Tors will advertise such + ciphersuites anyway. + + We cannot have the rule be "Tors must support every ECDHE ciphersuite + on the following list", since current Tors don't do all that, and + since one prominent Linux distribution builds OpenSSL without ECC + support because of patent/freedom fears. + + Fortunately, nearly every ciphersuite that we would like to advertise + to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0 + and later. This enables the following proposal to work: + +Proposed spec changes: + + I propose that the rules for handling ciphersuites at the server side + become the following: + + If the ciphersuites in the ClientHello contains no ciphers other than + the following[*], they indicate that the Tor v1 link protocol is in use. + + TLS_DHE_RSA_WITH_AES_256_CBC_SHA + TLS_DHE_RSA_WITH_AES_128_CBC_SHA + SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA + SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA + + If the advertised ciphersuites in the ClientHello are _exactly_[*] + the following, they indicate that the Tor v2+ link protocol is in + use, AND that the ClientHello may have unsupported ciphers. In this + case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or + DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher. + + TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA + TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA + TLS1_DHE_RSA_WITH_AES_256_SHA + TLS1_DHE_DSS_WITH_AES_256_SHA + TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA + TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA + TLS1_RSA_WITH_AES_256_SHA + TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA + TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA + TLS1_ECDHE_RSA_WITH_RC4_128_SHA + TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA + TLS1_DHE_RSA_WITH_AES_128_SHA + TLS1_DHE_DSS_WITH_AES_128_SHA + TLS1_ECDH_RSA_WITH_RC4_128_SHA + TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA + TLS1_ECDH_ECDSA_WITH_RC4_128_SHA + TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA + SSL3_RSA_RC4_128_MD5 + SSL3_RSA_RC4_128_SHA + TLS1_RSA_WITH_AES_128_SHA + TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA + TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA + SSL3_EDH_RSA_DES_192_CBC3_SHA + SSL3_EDH_DSS_DES_192_CBC3_SHA + TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA + TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA + SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA + SSL3_RSA_DES_192_CBC3_SHA + + [*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is + not counted when checking the list of ciphersuites. + + Otherwise, the ClientHello has these semantics: The inclusion of any + cipher supported by OpenSSL 1.0.0 means that the client supports it, + with the exception of + SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA + which is never supported. Clients MUST advertise support for at least one of + TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA. + + The server MUST choose a ciphersuite with ephemeral keys for forward + secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT + choose any cipher other than AES or 3DES. + +Discussion and consequences: + + + 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, wewill 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 + to use 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. + + + The proposed spec change above tries to future-proof ourselves by not + declaring that we support every declared cipher, in case we someday + need to handle a new Firefox version. If a new Firefox version + comes out that uses ciphers not supported by OpenSSL 1.0.0, we will + need to define whether clients may advertise its ciphers without + supporting them; but existing servers will continue working whether + we decide yes or no. + + + The restriction to "servers SHOULD only pick AES or 3DES" is meant to + reflect our current behavior, not to represent a permanent refusal to + support other ciphers. We can revisit it later as appropriate, if for + some bizarre reason Camellia or Seed or Aria becomes a better bet than + AES. + +Open question: + + Should the client drop connections if the server chooses a bad + cipher, or a suite without forward secrecy? +