[or-cvs] r12405: Add "Blocking resistant TLS certificate usage" as proposal 1 (in tor/trunk: . doc/spec/proposals)
nickm at seul.org
nickm at seul.org
Tue Nov 6 23:11:12 UTC 2007
Author: nickm
Date: 2007-11-06 18:11:12 -0500 (Tue, 06 Nov 2007)
New Revision: 12405
Added:
tor/trunk/doc/spec/proposals/124-tls-certificates.txt
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/000-index.txt
Log:
r16479 at catbus: nickm | 2007-11-06 18:10:02 -0500
Add "Blocking resistant TLS certificate usage" as proposal 124.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r16479] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-11-06 20:51:45 UTC (rev 12404)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-11-06 23:11:12 UTC (rev 12405)
@@ -27,7 +27,7 @@
102 Dropping "opt" from the directory format [CLOSED]
103 Splitting identity key from regularly used signing key [CLOSED]
104 Long and Short Router Descriptors [CLOSED]
-105 Version negotiation for the Tor protocol [OPEN]
+105 Version negotiation for the Tor protocol [ACCEPTED]
106 Checking fewer things during TLS handshakes [CLOSED]
107 Uptime Sanity Checking [CLOSED]
108 Base "Stable" Flag on Mean Time Between Failures [CLOSED]
@@ -46,12 +46,12 @@
121 Hidden Service Authentication [OPEN]
122 Network status entries need a new Unnamed flag [CLOSED]
123 Naming authorities automatically create bindings [OPEN]
+124 Blocking resistant TLS certificate usage [ACCEPTED]
Proposals by status:
OPEN:
- 105 Version negotiation for the Tor protocol
110 Avoiding infinite length circuits
113 Simplifying directory authority administration
114 Distributed Storage for Tor Hidden Service Descriptors
@@ -62,6 +62,8 @@
121 Hidden Service Authentication
123 Naming authorities automatically create bindings
ACCEPTED:
+ 105 Version negotiation for the Tor protocol
+ 124 Blocking resistant TLS certificate usage
NEEDS-RESEARCH:
118 Advertising multiple ORPorts at once
META:
Added: tor/trunk/doc/spec/proposals/124-tls-certificates.txt
===================================================================
--- tor/trunk/doc/spec/proposals/124-tls-certificates.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/124-tls-certificates.txt 2007-11-06 23:11:12 UTC (rev 12405)
@@ -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 [<length> 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 [<cert_length> 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 [<length> - 1 bytes]
+ Padding [PAYLOAD_LEN - <length> - 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)
+
+% <!-- Local IspellDict: american -->
Property changes on: tor/trunk/doc/spec/proposals/124-tls-certificates.txt
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
More information about the tor-commits
mailing list