Filename: 124-tls-certificates.txt Title: Blocking resistant TLS certificate usage Version: $Revision$ Last-Modified: $Date$ Author: Steven J. Murdoch Created: 2007-10-25 Status: Superseded Overview: To be less distinguishable from HTTPS web browsing, only Tor servers should present TLS certificates. This should be done whilst maintaining backwards compatibility with Tor nodes which present and expect client certificates, and while preserving existing security properties. This specification describes the negotiation protocol, what certificates should be presented during the TLS negotiation, and how to move the client authentication within the encrypted tunnel. Motivation: In Tor's current TLS [1] handshake, both client and server present a two-certificate chain. Since TLS performs authentication prior to establishing the encrypted tunnel, the contents of these certificates are visible to an eavesdropper. In contrast, during normal HTTPS web browsing, the server presents a single certificate, signed by a root CA and the client presents no certificate. Hence it is possible to distinguish Tor from HTTP by identifying this pattern. To resist blocking based on traffic identification, Tor should behave as close to HTTPS as possible, i.e. servers should offer a single certificate and not request a client certificate; clients should present no certificate. This presents two difficulties: clients are no longer authenticated and servers are authenticated by the connection key, rather than identity key. The link protocol must thus be modified to preserve the old security semantics. Finally, in order to maintain backwards compatibility, servers must correctly identify whether the client supports the modified certificate handling. This is achieved by modifying the cipher suites that clients advertise support for. These cipher suites are selected to be similar to those chosen by web browsers, in order to resist blocking based on client hello. Terminology: Initiator: OP or OR which initiates a TLS connection ("client" in TLS terminology) Responder: OR which receives an incoming TLS connection ("server" in TLS terminology) Version negotiation and cipher suite selection: In the modified TLS handshake, the responder does not request a certificate from the initiator. This request would normally occur immediately after the responder receives the client hello (the first message in a TLS handshake) and so the responder must decide whether to request a certificate based only on the information in the client hello. This is achieved by examining the cipher suites in the client hello. List 1: cipher suites lists offered by version 0/1 Tor From src/common/tortls.c, revision 12086: TLS1_TXT_DHE_RSA_WITH_AES_128_SHA TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA Client hello sent by initiator: Initiators supporting version 2 of the Tor connection protocol MUST offer a different cipher suite list from those sent by pre-version 2 Tors, contained in List 1. To maintain compatibility with older Tor versions and common browsers, the cipher suite list MUST include support for: 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 Client hello received by responder/server hello sent by responder: Responders supporting version 2 of the Tor connection protocol should compare the cipher suite list in the client hello with those in List 1. If it matches any in the list then the responder should assume that the initiatior supports version 1, and thus should maintain the version 1 behavior, i.e. send a two-certificate chain, request a client certificate and do not send or expect a VERSIONS cell [2]. Otherwise, the responder should assume version 2 behavior and select a cipher suite following TLS [1] behavior, i.e. select the first entry from the client hello cipher list which is acceptable. Responders MUST NOT select any suite that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits, or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT allow other SSLv3 ciphersuites. Should no mutually acceptable cipher suite be found, the connection MUST be closed. If the responder is implementing version 2 of the connection protocol it SHOULD send a server certificate with random contents. The organizationName field MUST NOT be "Tor", "TOR" or "t o r". Server certificate received by initiator: If the server certificate has an organizationName of "Tor", "TOR" or "t o r", the initiator should assume that the responder does not support version 2 of the connection protocol. In which case the initiator should respond following version 1, i.e. send a two-certificate client chain and do not send or expect a VERSIONS cell. [SJM: We could also use the fact that a client certificate request was sent] If the server hello contains a ciphersuite which does not comply with the key length requirements above, even if it was one offered in the client hello, the connection MUST be closed. This will only occur if the responder is not a Tor server. Backward compatibility: v1 Initiator, v1 Responder: No change v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator detects v1 server certificate and continues with v1 protocol v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator detects v2 server certificate and continues with v2 protocol. Additional link authentication process: Following VERSION and NETINFO negotiation, both responder and initiator MUST send a certification chain in a CERT cell. If one party does not have a certificate, the CERT cell MUST still be sent, but with a length of zero. A CERT cell is a variable length cell, of the format CircID [2 bytes] Command [1 byte] Length [2 bytes] Payload [ bytes] CircID MUST set to be 0x0000 Command is [SJM: TODO] Length is the length of the payload Payload contains 0 or more certificates, each is of the format: Cert_Length [2 bytes] Certificate [ bytes] Each certificate MUST sign the one preceding it. The initator MUST place its connection certificate first; the responder, having already sent its connection certificate as part of the TLS handshake MUST place its identity certificate first. Initiators who send a CERT cell MUST follow that with an LINK_AUTH cell to prove that they posess the corresponding private key. A LINK_AUTH cell is fixed-lenth, of the format: CircID [2 bytes] Command [1 byte] Length [2 bytes] Payload (padded with 0 bytes) [PAYLOAD_LEN - 2 bytes] CircID MUST set to be 0x0000 Command is [SJM: TODO] Length is the valid portion of the payload Payload is of the format: Signature version [1 byte] Signature [ - 1 bytes] Padding [PAYLOAD_LEN - - 2 bytes] Signature version: Identifies the type of signature, currently 0x00 Signature: Digital signature under the initiator's connection key of the following item, in PKCS #1 block type 1 [3] format: HMAC-SHA1, using the TLS master secret as key, of the following elements concatenated: - The signature version (0x00) - The NUL terminated ASCII string: "Tor initiator certificate verification" - client_random, as sent in the Client Hello - server_random, as sent in the Server Hello - SHA-1 hash of the initiator connection certificate - SHA-1 hash of the responder connection certificate Security checks: - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS connection is authenticated by the responder key. - For the handshake to have succeeded, the initiator MUST confirm: - That the TLS handshake was authenticated by the responder connection key - That the responder connection key was signed by the first certificate in the CERT cell - That each certificate in the CERT cell was signed by the following certificate, with the exception of the last - That the last certificate in the CERT cell is the expected identity certificate for the node being connected to - For the handshake to have succeeded, the responder MUST confirm either: A) - A zero length CERT cell was sent and no LINK_AUTH cell was sent In which case the responder shall treat the identity of the initiator as unknown or B) - That the LINK_AUTH MAC contains a signature by the first certificate in the CERT cell - That the MAC signed matches the expected value - That each certificate in the CERT cell was signed by the following certificate, with the exception of the last In which case the responder shall treat the identity of the initiator as that of the last certificate in the CERT cell Protocol summary: 1. I(nitiator) <-> R(esponder): TLS handshake, including responder authentication under connection certificate R_c 2. I <->: VERSION and NETINFO negotiation 3. R -> I: CERT (Responder identity certificate R_i (which signs R_c)) 4. I -> R: CERT (Initiator connection certificate I_c, Initiator identity certificate I_i (which signs I_c) 5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret, "Tor initiator certificate verification" || client_random || server_random || I_c hash || R_c hash) Notes: I -> R doesn't need to wait for R_i before sending its own messages (reduces round-trips). Certificate hash is calculated like identity hash in CREATE cells. Initiator signature is calculated in a similar way to Certificate Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7). If I is an OP, a zero length certificate chain may be sent in step 4; In which case, step 5 is not performed Rationale: - Version and netinfo negotiation before authentication: The version cell needs to come before before the rest of the protocol, since we may choose to alter the rest at some later point, e.g switch to a different MAC/signature scheme. It is useful to keep the NETINFO and VERSION cells close to each other, since the time between them is used to check if there is a delay-attack. Still, a server might want to not act on NETINFO data from an initiator until the authentication is complete. Appendix A: Cipher suite choices This specification intentionally does not put any constraints on the TLS ciphersuite lists presented by clients, other than a minimum required for compatibility. However, to maximize blocking resistance, ciphersuite lists should be carefully selected. Recommended client ciphersuite list Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h 0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 0x0035: TLS_RSA_WITH_AES_256_CBC_SHA 0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA 0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA 0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA 0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 0x0004: SSL_RSA_WITH_RC4_128_MD5 0x0005: SSL_RSA_WITH_RC4_128_SHA 0x002f: TLS_RSA_WITH_AES_128_CBC_SHA 0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC) 0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA Order specified in: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47 Recommended options: 0x0000: Server Name Indication [4] 0x000a: Supported Elliptic Curves [5] 0x000b: Supported Point Formats [5] Recommended compression: 0x00 Recommended server ciphersuite selection: The responder should select the first entry in this list which is listed in the client hello: 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA [ Common Firefox choice ] 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA [ Tor v1 default ] 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ] 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ] References: [1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF [2] Version negotiation for the Tor protocol, Tor proposal 105 [3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 1.5", RFC 2313, March 1998. [4] TLS Extensions, RFC 3546 [5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) %