1 Filename: 124-tls-certificates.txt
2 Title: Blocking resistant TLS certificate usage
5 Author: Steven J. Murdoch
11 To be less distinguishable from HTTPS web browsing, only Tor servers should
12 present TLS certificates. This should be done whilst maintaining backwards
13 compatibility with Tor nodes which present and expect client certificates, and
14 while preserving existing security properties. This specification describes
15 the negotiation protocol, what certificates should be presented during the TLS
16 negotiation, and how to move the client authentication within the encrypted
21 In Tor's current TLS [1] handshake, both client and server present a
22 two-certificate chain. Since TLS performs authentication prior to establishing
23 the encrypted tunnel, the contents of these certificates are visible to an
24 eavesdropper. In contrast, during normal HTTPS web browsing, the server
25 presents a single certificate, signed by a root CA and the client presents no
26 certificate. Hence it is possible to distinguish Tor from HTTP by identifying
29 To resist blocking based on traffic identification, Tor should behave as close
30 to HTTPS as possible, i.e. servers should offer a single certificate and not
31 request a client certificate; clients should present no certificate. This
32 presents two difficulties: clients are no longer authenticated and servers are
33 authenticated by the connection key, rather than identity key. The link
34 protocol must thus be modified to preserve the old security semantics.
36 Finally, in order to maintain backwards compatibility, servers must correctly
37 identify whether the client supports the modified certificate handling. This
38 is achieved by modifying the cipher suites that clients advertise support
39 for. These cipher suites are selected to be similar to those chosen by web
40 browsers, in order to resist blocking based on client hello.
44 Initiator: OP or OR which initiates a TLS connection ("client" in TLS
47 Responder: OR which receives an incoming TLS connection ("server" in TLS
50 Version negotiation and cipher suite selection:
52 In the modified TLS handshake, the responder does not request a certificate
53 from the initiator. This request would normally occur immediately after the
54 responder receives the client hello (the first message in a TLS handshake) and
55 so the responder must decide whether to request a certificate based only on
56 the information in the client hello. This is achieved by examining the cipher
57 suites in the client hello.
59 List 1: cipher suites lists offered by version 0/1 Tor
61 From src/common/tortls.c, revision 12086:
62 TLS1_TXT_DHE_RSA_WITH_AES_128_SHA
63 TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
64 SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
66 Client hello sent by initiator:
68 Initiators supporting version 2 of the Tor connection protocol MUST
69 offer a different cipher suite list from those sent by pre-version 2
70 Tors, contained in List 1. To maintain compatibility with older Tor
71 versions and common browsers, the cipher suite list MUST include
74 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
75 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
76 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
77 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
79 Client hello received by responder/server hello sent by responder:
81 Responders supporting version 2 of the Tor connection protocol should compare
82 the cipher suite list in the client hello with those in List 1. If it matches
83 any in the list then the responder should assume that the initiatior supports
84 version 1, and thus should maintain the version 1 behavior, i.e. send a
85 two-certificate chain, request a client certificate and do not send or expect
88 Otherwise, the responder should assume version 2 behavior and select a cipher
89 suite following TLS [1] behavior, i.e. select the first entry from the client
90 hello cipher list which is acceptable. Responders MUST NOT select any suite
91 that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits,
92 or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT
93 allow other SSLv3 ciphersuites.
95 Should no mutually acceptable cipher suite be found, the connection MUST be
98 If the responder is implementing version 2 of the connection protocol it
99 SHOULD send a server certificate with random contents. The organizationName
100 field MUST NOT be "Tor", "TOR" or "t o r".
102 Server certificate received by initiator:
104 If the server certificate has an organizationName of "Tor", "TOR" or "t o r",
105 the initiator should assume that the responder does not support version 2 of
106 the connection protocol. In which case the initiator should respond following
107 version 1, i.e. send a two-certificate client chain and do not send or expect
110 [SJM: We could also use the fact that a client certificate request was sent]
112 If the server hello contains a ciphersuite which does not comply with the key
113 length requirements above, even if it was one offered in the client hello, the
114 connection MUST be closed. This will only occur if the responder is not a Tor
117 Backward compatibility:
119 v1 Initiator, v1 Responder: No change
120 v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello
121 v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator
122 detects v1 server certificate and continues with v1 protocol
123 v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator
124 detects v2 server certificate and continues with v2 protocol.
126 Additional link authentication process:
128 Following VERSION and NETINFO negotiation, both responder and
129 initiator MUST send a certification chain in a CERT cell. If one
130 party does not have a certificate, the CERT cell MUST still be sent,
131 but with a length of zero.
133 A CERT cell is a variable length cell, of the format
137 Payload [<length> bytes]
139 CircID MUST set to be 0x0000
140 Command is [SJM: TODO]
141 Length is the length of the payload
142 Payload contains 0 or more certificates, each is of the format:
143 Cert_Length [2 bytes]
144 Certificate [<cert_length> bytes]
146 Each certificate MUST sign the one preceding it. The initator MUST
147 place its connection certificate first; the responder, having
148 already sent its connection certificate as part of the TLS handshake
149 MUST place its identity certificate first.
151 Initiators who send a CERT cell MUST follow that with an LINK_AUTH
152 cell to prove that they posess the corresponding private key.
154 A LINK_AUTH cell is fixed-lenth, of the format:
158 Payload (padded with 0 bytes) [PAYLOAD_LEN - 2 bytes]
160 CircID MUST set to be 0x0000
161 Command is [SJM: TODO]
162 Length is the valid portion of the payload
163 Payload is of the format:
164 Signature version [1 byte]
165 Signature [<length> - 1 bytes]
166 Padding [PAYLOAD_LEN - <length> - 2 bytes]
168 Signature version: Identifies the type of signature, currently 0x00
169 Signature: Digital signature under the initiator's connection key of the
170 following item, in PKCS #1 block type 1 [3] format:
172 HMAC-SHA1, using the TLS master secret as key, of the
173 following elements concatenated:
174 - The signature version (0x00)
175 - The NUL terminated ASCII string: "Tor initiator certificate verification"
176 - client_random, as sent in the Client Hello
177 - server_random, as sent in the Server Hello
178 - SHA-1 hash of the initiator connection certificate
179 - SHA-1 hash of the responder connection certificate
183 - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS
184 connection is authenticated by the responder key.
185 - For the handshake to have succeeded, the initiator MUST confirm:
186 - That the TLS handshake was authenticated by the
187 responder connection key
188 - That the responder connection key was signed by the first
189 certificate in the CERT cell
190 - That each certificate in the CERT cell was signed by the
191 following certificate, with the exception of the last
192 - That the last certificate in the CERT cell is the expected
193 identity certificate for the node being connected to
194 - For the handshake to have succeeded, the responder MUST confirm
196 A) - A zero length CERT cell was sent and no LINK_AUTH cell was
198 In which case the responder shall treat the identity of the
201 B) - That the LINK_AUTH MAC contains a signature by the first
202 certificate in the CERT cell
203 - That the MAC signed matches the expected value
204 - That each certificate in the CERT cell was signed by the
205 following certificate, with the exception of the last
206 In which case the responder shall treat the identity of the
207 initiator as that of the last certificate in the CERT cell
211 1. I(nitiator) <-> R(esponder): TLS handshake, including responder
212 authentication under connection certificate R_c
213 2. I <->: VERSION and NETINFO negotiation
214 3. R -> I: CERT (Responder identity certificate R_i (which signs R_c))
215 4. I -> R: CERT (Initiator connection certificate I_c,
216 Initiator identity certificate I_i (which signs I_c)
217 5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret,
218 "Tor initiator certificate verification" ||
219 client_random || server_random ||
220 I_c hash || R_c hash)
222 Notes: I -> R doesn't need to wait for R_i before sending its own
223 messages (reduces round-trips).
224 Certificate hash is calculated like identity hash in CREATE cells.
225 Initiator signature is calculated in a similar way to Certificate
226 Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7).
227 If I is an OP, a zero length certificate chain may be sent in step 4;
228 In which case, step 5 is not performed
232 - Version and netinfo negotiation before authentication: The version cell needs
233 to come before before the rest of the protocol, since we may choose to alter
234 the rest at some later point, e.g switch to a different MAC/signature scheme.
235 It is useful to keep the NETINFO and VERSION cells close to each other, since
236 the time between them is used to check if there is a delay-attack. Still, a
237 server might want to not act on NETINFO data from an initiator until the
238 authentication is complete.
240 Appendix A: Cipher suite choices
242 This specification intentionally does not put any constraints on the
243 TLS ciphersuite lists presented by clients, other than a minimum
244 required for compatibility. However, to maximize blocking
245 resistance, ciphersuite lists should be carefully selected.
247 Recommended client ciphersuite list
249 Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h
251 0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
252 0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
253 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
254 0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
255 0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
256 0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
257 0x0035: TLS_RSA_WITH_AES_256_CBC_SHA
258 0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
259 0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
260 0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA
261 0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
262 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
263 0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
264 0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA
265 0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
266 0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA
267 0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
268 0x0004: SSL_RSA_WITH_RC4_128_MD5
269 0x0005: SSL_RSA_WITH_RC4_128_SHA
270 0x002f: TLS_RSA_WITH_AES_128_CBC_SHA
271 0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
272 0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
273 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
274 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
275 0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
276 0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
277 0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC)
278 0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA
281 http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47
284 0x0000: Server Name Indication [4]
285 0x000a: Supported Elliptic Curves [5]
286 0x000b: Supported Point Formats [5]
288 Recommended compression:
291 Recommended server ciphersuite selection:
293 The responder should select the first entry in this list which is
294 listed in the client hello:
296 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA [ Common Firefox choice ]
297 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA [ Tor v1 default ]
298 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ]
299 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ]
303 [1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF
305 [2] Version negotiation for the Tor protocol, Tor proposal 105
307 [3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
308 RSA Cryptography Specifications Version 1.5", RFC 2313,
311 [4] TLS Extensions, RFC 3546
313 [5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
315 % <!-- Local IspellDict: american -->