proposals/198-restore-clienthello-semantics.txt

   1 Filename: 198-restore-clienthello-semantics.txt
   2 Title: Restore semantics of TLS ClientHello
   3 Author: Nick Mathewson
   4 Created: 19-Mar-2012
   5 Status: Accepted
   6 Target: 0.2.4.x
   7
   8 Status:
   9
  10    Tor 0.2.3.17-beta implements the client-side changes, and no longer
  11    advertises openssl-supported TLS ciphersuites we don't have.
  12
  13 Overview:
  14
  15    Currently, all supported Tor versions try to imitate an older version
  16    of Firefox when advertising ciphers in their TLS ClientHello.  This
  17    feature is intended to make it harder for a censor to distinguish a
  18    Tor client from other TLS traffic.  Unfortunately, it makes the
  19    contents of the ClientHello unreliable: a server cannot conclude that
  20    a cipher is really supported by a Tor client simply because it is
  21    advertised in the ClientHello.
  22
  23    This proposal suggests an approach for restoring sanity to our use of
  24    ClientHello, so that we still avoid ciphersuite-based fingerprinting,
  25    but allow nodes to negotiate better ciphersuites than they are
  26    allowed to negotiate today.
  27
  28 Background reading:
  29
  30    Section 2 of tor-spec.txt 2 describes our current baroque link
  31    negotiation scheme.  Proposals 176 and 184 describe more information
  32    about how it got that way.
  33
  34    Bug 4744 is a big part of the motivation for this proposal: we want
  35    to allow Tors to advertise even more ciphers, some of which we would
  36    actually prefer to the ones we are using now.
  37
  38    What you need to know about the TLS handshake is that the client
  39    sends a list of all the ciphersuites that it supports in its
  40    ClientHello message, and then the server chooses one and tells the
  41    client which one it picked.
  42
  43 Motivation and constraints:
  44
  45    We'd like to use some of the ECDHE TLS ciphersuites, since they allow
  46    us to get better forward-secrecy at lower cost than our current
  47    DH-1024 usage.  But right now, we can't ever use them, since Tor will
  48    advertise them whether or not it has a version of OpenSSL that
  49    supports them.
  50
  51    (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL
  52    before 1.0.0e or so had some security issues with them.)
  53
  54    We cannot have the rule be "Tors must only advertise ciphersuites
  55    that they can use", since current Tors will advertise such
  56    ciphersuites anyway.
  57
  58    We cannot have the rule be "Tors must support every ECDHE ciphersuite
  59    on the following list", since current Tors don't do all that, and
  60    since one prominent Linux distribution builds OpenSSL without ECC
  61    support because of patent/freedom fears.
  62
  63    Fortunately, nearly every ciphersuite that we would like to advertise
  64    to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0
  65    and later.  This enables the following proposal to work:
  66
  67 Proposed spec changes:
  68
  69    I propose that the rules for handling ciphersuites at the server side
  70    become the following:
  71
  72    If the ciphersuites in the ClientHello contains no ciphers other than
  73    the following[*], they indicate that the Tor v1 link protocol is in use.
  74
  75      TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  76      TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  77      SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  78      SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  79
  80    If the advertised ciphersuites in the ClientHello are _exactly_[*]
  81    the following, they indicate that the Tor v2+ link protocol is in
  82    use, AND that the ClientHello may have unsupported ciphers.  In this
  83    case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA  or
  84    DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher.
  85
  86      TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  87      TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA
  88      TLS1_DHE_RSA_WITH_AES_256_SHA
  89      TLS1_DHE_DSS_WITH_AES_256_SHA
  90      TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA
  91      TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA
  92      TLS1_RSA_WITH_AES_256_SHA
  93      TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA
  94      TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  95      TLS1_ECDHE_RSA_WITH_RC4_128_SHA
  96      TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA
  97      TLS1_DHE_RSA_WITH_AES_128_SHA
  98      TLS1_DHE_DSS_WITH_AES_128_SHA
  99      TLS1_ECDH_RSA_WITH_RC4_128_SHA
 100      TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA
 101      TLS1_ECDH_ECDSA_WITH_RC4_128_SHA
 102      TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA
 103      SSL3_RSA_RC4_128_MD5
 104      SSL3_RSA_RC4_128_SHA
 105      TLS1_RSA_WITH_AES_128_SHA
 106      TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA
 107      TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA
 108      SSL3_EDH_RSA_DES_192_CBC3_SHA
 109      SSL3_EDH_DSS_DES_192_CBC3_SHA
 110      TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA
 111      TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA
 112      SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
 113      SSL3_RSA_DES_192_CBC3_SHA
 114
 115   [*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is
 116       not counted when checking the list of ciphersuites.
 117
 118   Otherwise, the ClientHello has these semantics: The inclusion of any
 119   cipher supported by OpenSSL 1.0.0 means that the client supports it,
 120   with the exception of
 121       SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
 122   which is never supported. Clients MUST advertise support for at least one of
 123   TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
 124
 125   The server MUST choose a ciphersuite with ephemeral keys for forward
 126   secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT
 127   choose any cipher other than AES or 3DES.
 128
 129 Discussion and consequences:
 130
 131
 132   Currently, OpenSSL 1.0.0 (in its default configuration) supports every
 133   cipher that we would need in order to give the same list as Firefox
 134   versions 8 through 11 give in their default configuration, with the
 135   exception of the FIPS ciphersuite above.  Therefore, we will be able
 136   to fake the new ciphersuite list correctly in all of our bundles that
 137   include OpenSSL, and on every version of Unix that keeps up-to-date.
 138
 139   However, versions of Tor compiled to use older versions of OpenSSL, or
 140   versions of OpenSSL with some ciphersuites disabled, will no
 141   longer give the same ciphersuite lists as other versions of Tor.  On
 142   these platforms, Tor clients will no longer impersonate Firefox.
 143   Users who need to do so will have to download one of our bundles, or
 144   use a non-system OpenSSL.
 145
 146
 147   The proposed spec change above tries to future-proof ourselves by not
 148   declaring that we support every declared cipher, in case we someday
 149   need to handle a new Firefox version.  If a new Firefox version
 150   comes out that uses ciphers not supported by OpenSSL 1.0.0, we will
 151   need to define whether clients may advertise its ciphers without
 152   supporting them; but existing servers will continue working whether
 153   we decide yes or no.
 154
 155
 156   The restriction to "servers SHOULD only pick AES or 3DES" is meant to
 157   reflect our current behavior, not to represent a permanent refusal to
 158   support other ciphers.  We can revisit it later as appropriate, if for
 159   some bizarre reason Camellia or Seed or Aria becomes a better bet than
 160   AES.
 161
 162 Open questions:
 163
 164   Should the client drop connections if the server chooses a bad
 165   cipher, or a suite without forward secrecy?
 166
 167   Can we get OpenSSL to support the dubious FIPS suite excluded above,
 168   in order to remove a distinguishing opportunity?  It is not so simple
 169   as just editing the SSL_CIPHER list in s3_lib.c, since the nonstandard
 170   SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher is (IIUC) defined to use the
 171   TLS1 KDF, while declaring itself to be an SSL cipher (!).
 172
 173   Can we do anything to eventually allow the IE7+[**] cipher list as
 174   well?  IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or
 175   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current
 176   Tor servers, which _only_ support those.  It looks like the only
 177   forward-secure ciphersuites that IE7+ *does* support are ECDHE ones,
 178   and DHE+DSS ones.  So if we want this flexibility, we could mandate
 179   server-side ECDHE, or somehow get DHE+DSS support (which would play
 180   havoc with our current certificate generation code IIUC), or say that
 181   it is sometimes acceptable to have a non-forward-secure link
 182   protocol[***].  None of these answers seems like a great one.  Is one
 183   best?  Are there other options?
 184
 185   [**] Actually, I think it's the Windows SChannel cipher list we
 186   should be looking at here.
 187   [***] If we did _that_, we'd want to specify that CREATE_FAST could
 188   never be used on a non-forward-secure link.  Even so, I don't like the
 189   implications of leaking cell types and circuit IDs to a future
 190   compromise.
 191