[tor-commits] [torspec/master] Merge proposal 198 into tor-spec.txt
nickm at torproject.org
nickm at torproject.org
Mon Jun 18 16:13:32 UTC 2012
commit 1c30043671507c521cfa6150c554d7028e1daf96
Author: Nick Mathewson <nickm at torproject.org>
Date: Fri Jun 15 17:07:18 2012 -0400
Merge proposal 198 into tor-spec.txt
The client side is implemented in 0.2.3.17-beta; technically, we are
in compliance with the server side.
---
tor-spec.txt | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt
index 28a51c9..86aa49f 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -189,10 +189,8 @@ see tor-design.pdf.
party sending a two-certificate chain as in "certificates up-front".
The initiator's ClientHello MUST include at least one ciphersuite not in
the list above -- that's how the initiator indicates that it can
- handle this handshake. The responder SHOULD NOT select any
- ciphersuite besides those in the list above.
- [The above "should not" is because some of the ciphers that
- clients list may be fake.]
+ handle this handshake. For other considerations on the initiator's
+ ClientHello, see section 2.1 below.
In "in-protocol" (a.k.a. "the v3 handshake"), the initiator sends no
certificates, and the
@@ -249,11 +247,6 @@ see tor-design.pdf.
initiator SHOULD choose a list of ciphersuites and TLS extensions
to mimic one used by a popular web browser.
- Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys,
- or whose symmetric keys are less then KEY_LEN bits, or whose digests are
- less than HASH_LEN bits. Responders SHOULD NOT select any SSLv3
- ciphersuite other than those listed above.
-
Even though the connection protocol is identical, we will think of the
initiator as either an onion router (OR) if it is willing to relay
traffic for other Tor users, or an onion proxy (OP) if it only handles
@@ -299,6 +292,62 @@ see tor-design.pdf.
their IP address changes. Clients MAY send certificates using any
of the above handshake variants.
+2.1. Picking TLS ciphersuites
+
+ Clients SHOULD send a ciphersuite list chosen to emulate some popular
+ web browser or other program common on the internet. Clients may send
+ the "Fixed Cipheruite List" below. If they do not, they MUST NOT
+ advertise any ciphersuite that they cannot actually support, unless that
+ cipher is one not supported by OpenSSL 1.0.1.
+
+ The fixed ciphersuite list is:
+ TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+ TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA
+ TLS1_DHE_RSA_WITH_AES_256_SHA
+ TLS1_DHE_DSS_WITH_AES_256_SHA
+ TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA
+ TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA
+ TLS1_RSA_WITH_AES_256_SHA
+ TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA
+ TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+ TLS1_ECDHE_RSA_WITH_RC4_128_SHA
+ TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA
+ TLS1_DHE_RSA_WITH_AES_128_SHA
+ TLS1_DHE_DSS_WITH_AES_128_SHA
+ TLS1_ECDH_RSA_WITH_RC4_128_SHA
+ TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA
+ TLS1_ECDH_ECDSA_WITH_RC4_128_SHA
+ TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA
+ SSL3_RSA_RC4_128_MD5
+ SSL3_RSA_RC4_128_SHA
+ TLS1_RSA_WITH_AES_128_SHA
+ TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA
+ TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA
+ SSL3_EDH_RSA_DES_192_CBC3_SHA
+ SSL3_EDH_DSS_DES_192_CBC3_SHA
+ TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA
+ TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA
+ SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
+ SSL3_RSA_DES_192_CBC3_SHA
+ [*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is
+ not counted when checking the list of ciphersuites.
+
+ If the client sends the Fixed Ciphersuite List, the responder MUST NOT
+ select any ciphersuite besides TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
+ TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and
+ SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA: such ciphers might not actually be
+ supported by the client.
+
+ If the client sends a v2+ ClientHello with a list of ciphers other then
+ the Fixed Ciphersuite List, the responder can trust that the client
+ supports every cipher advertised in that list, so long as that ciphersuite
+ is also supported by OpenSSL 1.0.1.
+
+ Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys,
+ or whose symmetric keys are less then KEY_LEN bits, or whose digests are
+ less than HASH_LEN bits. Responders SHOULD NOT select any SSLv3
+ ciphersuite other than the DHE+3DES suites listed above.
+
3. Cell Packet format
The basic unit of communication for onion routers and onion
More information about the tor-commits
mailing list