mirror of
https://github.com/torproject/torspec.git
synced 2024-11-24 02:09:50 +00:00
6bd09d5076
Tor doesn't use SVN anymore, making $Revision$, $Id$ and $Date$ meaningless. Remove them without replacement.
314 lines
14 KiB
Plaintext
314 lines
14 KiB
Plaintext
Filename: 124-tls-certificates.txt
|
|
Title: Blocking resistant TLS certificate usage
|
|
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 -->
|