[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