123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315 |
- 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 [<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 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 [<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 -->
|