From 7c737f8cf224e9242798c3b0035d6cbb26df1307 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 6 Nov 2007 23:11:12 +0000 Subject: r16479@catbus: nickm | 2007-11-06 18:10:02 -0500 Add "Blocking resistant TLS certificate usage" as proposal 124. svn:r12405 --- proposals/124-tls-certificates.txt | 315 +++++++++++++++++++++++++++++++++++++ 1 file changed, 315 insertions(+) create mode 100644 proposals/124-tls-certificates.txt (limited to 'proposals/124-tls-certificates.txt') diff --git a/proposals/124-tls-certificates.txt b/proposals/124-tls-certificates.txt new file mode 100644 index 0000000..bbad5af --- /dev/null +++ b/proposals/124-tls-certificates.txt @@ -0,0 +1,315 @@ +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: Accepted + +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 should 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 prececeding 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) + +% -- cgit v1.2.3-54-g00ecf