doc/spec/proposals/124-tls-certificates.txt

   1 Filename: 124-tls-certificates.txt
   2 Title: Blocking resistant TLS certificate usage
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Steven J. Murdoch
   6 Created: 2007-10-25
   7 Status: Superseded
   8
   9 Overview:
  10
  11   To be less distinguishable from HTTPS web browsing, only Tor servers should
  12   present TLS certificates. This should be done whilst maintaining backwards
  13   compatibility with Tor nodes which present and expect client certificates, and
  14   while preserving existing security properties. This specification describes
  15   the negotiation protocol, what certificates should be presented during the TLS
  16   negotiation, and how to move the client authentication within the encrypted
  17   tunnel.
  18
  19 Motivation:
  20
  21   In Tor's current TLS [1] handshake, both client and server present a
  22   two-certificate chain. Since TLS performs authentication prior to establishing
  23   the encrypted tunnel, the contents of these certificates are visible to an
  24   eavesdropper. In contrast, during normal HTTPS web browsing, the server
  25   presents a single certificate, signed by a root CA and the client presents no
  26   certificate. Hence it is possible to distinguish Tor from HTTP by identifying
  27   this pattern.
  28
  29   To resist blocking based on traffic identification, Tor should behave as close
  30   to HTTPS as possible, i.e. servers should offer a single certificate and not
  31   request a client certificate; clients should present no certificate. This
  32   presents two difficulties: clients are no longer authenticated and servers are
  33   authenticated by the connection key, rather than identity key. The link
  34   protocol must thus be modified to preserve the old security semantics.
  35
  36   Finally, in order to maintain backwards compatibility, servers must correctly
  37   identify whether the client supports the modified certificate handling. This
  38   is achieved by modifying the cipher suites that clients advertise support
  39   for. These cipher suites are selected to be similar to those chosen by web
  40   browsers, in order to resist blocking based on client hello.
  41
  42 Terminology:
  43
  44   Initiator: OP or OR which initiates a TLS connection ("client" in TLS
  45    terminology)
  46
  47   Responder: OR which receives an incoming TLS connection ("server" in TLS
  48    terminology)
  49
  50 Version negotiation and cipher suite selection:
  51
  52   In the modified TLS handshake, the responder does not request a certificate
  53   from the initiator. This request would normally occur immediately after the
  54   responder receives the client hello (the first message in a TLS handshake) and
  55   so the responder must decide whether to request a certificate based only on
  56   the information in the client hello. This is achieved by examining the cipher
  57   suites in the client hello.
  58
  59    List 1: cipher suites lists offered by version 0/1 Tor
  60
  61    From src/common/tortls.c, revision 12086:
  62     TLS1_TXT_DHE_RSA_WITH_AES_128_SHA
  63     TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
  64     SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
  65
  66  Client hello sent by initiator:
  67
  68   Initiators supporting version 2 of the Tor connection protocol MUST
  69   offer a different cipher suite list from those sent by pre-version 2
  70   Tors, contained in List 1. To maintain compatibility with older Tor
  71   versions and common browsers, the cipher suite list MUST include
  72   support for:
  73
  74    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  75    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  76    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  77    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  78
  79  Client hello received by responder/server hello sent by responder:
  80
  81   Responders supporting version 2 of the Tor connection protocol should compare
  82   the cipher suite list in the client hello with those in List 1. If it matches
  83   any in the list then the responder should assume that the initiatior supports
  84   version 1, and thus should maintain the version 1 behavior, i.e. send a
  85   two-certificate chain, request a client certificate and do not send or expect
  86   a VERSIONS cell [2].
  87
  88   Otherwise, the responder should assume version 2 behavior and select a cipher
  89   suite following TLS [1] behavior, i.e. select the first entry from the client
  90   hello cipher list which is acceptable. Responders MUST NOT select any suite
  91   that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits,
  92   or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT
  93   allow other SSLv3 ciphersuites.
  94
  95   Should no mutually acceptable cipher suite be found, the connection MUST be
  96   closed.
  97
  98   If the responder is implementing version 2 of the connection protocol it
  99   SHOULD send a server certificate with random contents. The organizationName
 100   field MUST NOT be "Tor", "TOR" or "t o r".
 101
 102  Server certificate received by initiator:
 103
 104   If the server certificate has an organizationName of "Tor", "TOR" or "t o r",
 105   the initiator should assume that the responder does not support version 2 of
 106   the connection protocol. In which case the initiator should respond following
 107   version 1, i.e. send a two-certificate client chain and do not send or expect
 108   a VERSIONS cell.
 109
 110   [SJM: We could also use the fact that a client certificate request was sent]
 111
 112   If the server hello contains a ciphersuite which does not comply with the key
 113   length requirements above, even if it was one offered in the client hello, the
 114   connection MUST be closed. This will only occur if the responder is not a Tor
 115   server.
 116
 117  Backward compatibility:
 118
 119   v1 Initiator, v1 Responder: No change
 120   v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello
 121   v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator
 122    detects v1 server certificate and continues with v1 protocol
 123   v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator
 124    detects v2 server certificate and continues with v2 protocol.
 125
 126  Additional link authentication process:
 127
 128   Following VERSION and NETINFO negotiation, both responder and
 129   initiator MUST send a certification chain in a CERT cell. If one
 130   party does not have a certificate, the CERT cell MUST still be sent,
 131   but with a length of zero.
 132
 133   A CERT cell is a variable length cell, of the format
 134         CircID                                [2 bytes]
 135         Command                               [1 byte]
 136         Length                                [2 bytes]
 137         Payload                               [<length> bytes]
 138
 139   CircID MUST set to be 0x0000
 140   Command is [SJM: TODO]
 141   Length is the length of the payload
 142   Payload contains 0 or more certificates, each is of the format:
 143         Cert_Length  [2 bytes]
 144         Certificate  [<cert_length> bytes]
 145
 146   Each certificate MUST sign the one preceding it. The initator MUST
 147   place its connection certificate first; the responder, having
 148   already sent its connection certificate as part of the TLS handshake
 149   MUST place its identity certificate first.
 150
 151   Initiators who send a CERT cell MUST follow that with an LINK_AUTH
 152   cell to prove that they posess the corresponding private key.
 153
 154   A LINK_AUTH cell is fixed-lenth, of the format:
 155          CircID                                [2 bytes]
 156          Command                               [1 byte]
 157          Length                                [2 bytes]
 158          Payload (padded with 0 bytes)         [PAYLOAD_LEN - 2 bytes]
 159
 160   CircID MUST set to be 0x0000
 161   Command is [SJM: TODO]
 162   Length is the valid portion of the payload
 163   Payload is of the format:
 164          Signature version                     [1 byte]
 165          Signature                             [<length> - 1 bytes]
 166          Padding                               [PAYLOAD_LEN - <length> - 2 bytes]
 167
 168   Signature version: Identifies the type of signature, currently 0x00
 169   Signature: Digital signature under the initiator's connection key of the
 170    following item, in PKCS #1 block type 1 [3] format:
 171
 172     HMAC-SHA1, using the TLS master secret as key, of the
 173     following elements concatenated:
 174      - The signature version (0x00)
 175      - The NUL terminated ASCII string: "Tor initiator certificate verification"
 176      - client_random, as sent in the Client Hello
 177      - server_random, as sent in the Server Hello
 178      - SHA-1 hash of the initiator connection certificate
 179      - SHA-1 hash of the responder connection certificate
 180
 181   Security checks:
 182
 183     - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS
 184       connection is authenticated by the responder key.
 185     - For the handshake to have succeeded, the initiator MUST confirm:
 186        - That the TLS handshake was authenticated by the
 187          responder connection key
 188        - That the responder connection key was signed by the first
 189          certificate in the CERT cell
 190        - That each certificate in the CERT cell was signed by the
 191          following certificate, with the exception of the last
 192        - That the last certificate in the CERT cell is the expected
 193          identity certificate for the node being connected to
 194     - For the handshake to have succeeded, the responder MUST confirm
 195       either:
 196        A) - A zero length CERT cell was sent and no LINK_AUTH cell was
 197             sent
 198           In which case the responder shall treat the identity of the
 199           initiator as unknown
 200         or
 201        B) - That the LINK_AUTH MAC contains a signature by the first
 202             certificate in the CERT cell
 203           - That the MAC signed matches the expected value
 204           - That each certificate in the CERT cell was signed by the
 205             following certificate, with the exception of the last
 206           In which case the responder shall treat the identity of the
 207           initiator as that of the last certificate in the CERT cell
 208
 209   Protocol summary:
 210
 211   1. I(nitiator) <-> R(esponder): TLS handshake, including responder
 212                                authentication under connection certificate R_c
 213   2. I <->: VERSION and NETINFO negotiation
 214   3. R -> I: CERT (Responder identity certificate R_i (which signs R_c))
 215   4. I -> R: CERT (Initiator connection certificate I_c,
 216                    Initiator identity certificate I_i (which signs I_c)
 217   5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret,
 218                     "Tor initiator certificate verification" ||
 219                     client_random || server_random ||
 220                     I_c hash || R_c hash)
 221
 222   Notes: I -> R doesn't need to wait for R_i before sending its own
 223    messages (reduces round-trips).
 224    Certificate hash is calculated like identity hash in CREATE cells.
 225    Initiator signature is calculated in a similar way to Certificate
 226    Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7).
 227    If I is an OP, a zero length certificate chain may be sent in step 4;
 228    In which case, step 5 is not performed
 229
 230   Rationale:
 231
 232   - Version and netinfo negotiation before authentication: The version cell needs
 233    to come before before the rest of the protocol, since we may choose to alter
 234    the rest at some later point, e.g switch to a different MAC/signature scheme.
 235    It is useful to keep the NETINFO and VERSION cells close to each other, since
 236    the time between them is used to check if there is a delay-attack. Still, a
 237    server might want to not act on NETINFO data from an initiator until the
 238    authentication is complete.
 239
 240 Appendix A: Cipher suite choices
 241
 242   This specification intentionally does not put any constraints on the
 243   TLS ciphersuite lists presented by clients, other than a minimum
 244   required for compatibility. However, to maximize blocking
 245   resistance, ciphersuite lists should be carefully selected.
 246
 247    Recommended client ciphersuite list
 248
 249      Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h
 250
 251      0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 252      0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 253      0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 254      0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
 255      0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
 256      0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
 257      0x0035: TLS_RSA_WITH_AES_256_CBC_SHA
 258      0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
 259      0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 260      0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA
 261      0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 262      0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
 263      0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
 264      0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA
 265      0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
 266      0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA
 267      0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
 268      0x0004: SSL_RSA_WITH_RC4_128_MD5
 269      0x0005: SSL_RSA_WITH_RC4_128_SHA
 270      0x002f: TLS_RSA_WITH_AES_128_CBC_SHA
 271      0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
 272      0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
 273      0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
 274      0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 275      0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
 276      0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
 277      0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC)
 278      0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA
 279
 280      Order specified in:
 281       http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47
 282
 283    Recommended options:
 284       0x0000: Server Name Indication [4]
 285       0x000a: Supported Elliptic Curves [5]
 286       0x000b: Supported Point Formats [5]
 287
 288    Recommended compression:
 289       0x00
 290
 291    Recommended server ciphersuite selection:
 292
 293      The responder should select the first entry in this list which is
 294      listed in the client hello:
 295
 296      0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA  [ Common Firefox choice ]
 297      0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA  [ Tor v1 default ]
 298      0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ]
 299      0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ]
 300
 301 References:
 302
 303 [1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF
 304
 305 [2] Version negotiation for the Tor protocol, Tor proposal 105
 306
 307 [3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
 308     RSA Cryptography Specifications Version 1.5", RFC 2313,
 309     March 1998.
 310
 311 [4] TLS Extensions, RFC 3546
 312
 313 [5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
 314
 315 % <!-- Local IspellDict: american -->