proposals/124-tls-certificates.txt

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