-
Notifications
You must be signed in to change notification settings - Fork 84
/
198-restore-clienthello-semantics.txt
190 lines (152 loc) · 8.08 KB
/
198-restore-clienthello-semantics.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
Filename: 198-restore-clienthello-semantics.txt
Title: Restore semantics of TLS ClientHello
Author: Nick Mathewson
Created: 19-Mar-2012
Status: Closed
Target: 0.2.4.x
Status:
Tor 0.2.3.17-beta implements the client-side changes, and no longer
advertises openssl-supported TLS ciphersuites we don't have.
Overview:
Currently, all supported Tor versions try to imitate an older version
of Firefox when advertising ciphers in their TLS ClientHello. This
feature is intended to make it harder for a censor to distinguish a
Tor client from other TLS traffic. Unfortunately, it makes the
contents of the ClientHello unreliable: a server cannot conclude that
a cipher is really supported by a Tor client simply because it is
advertised in the ClientHello.
This proposal suggests an approach for restoring sanity to our use of
ClientHello, so that we still avoid ciphersuite-based fingerprinting,
but allow nodes to negotiate better ciphersuites than they are
allowed to negotiate today.
Background reading:
Section 2 of tor-spec.txt 2 describes our current baroque link
negotiation scheme. Proposals 176 and 184 describe more information
about how it got that way.
Bug 4744 is a big part of the motivation for this proposal: we want
to allow Tors to advertise even more ciphers, some of which we would
actually prefer to the ones we are using now.
What you need to know about the TLS handshake is that the client
sends a list of all the ciphersuites that it supports in its
ClientHello message, and then the server chooses one and tells the
client which one it picked.
Motivation and constraints:
We'd like to use some of the ECDHE TLS ciphersuites, since they allow
us to get better forward-secrecy at lower cost than our current
DH-1024 usage. But right now, we can't ever use them, since Tor will
advertise them whether or not it has a version of OpenSSL that
supports them.
(OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL
before 1.0.0e or so had some security issues with them.)
We cannot have the rule be "Tors must only advertise ciphersuites
that they can use", since current Tors will advertise such
ciphersuites anyway.
We cannot have the rule be "Tors must support every ECDHE ciphersuite
on the following list", since current Tors don't do all that, and
since one prominent Linux distribution builds OpenSSL without ECC
support because of patent/freedom fears.
Fortunately, nearly every ciphersuite that we would like to advertise
to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0
and later. This enables the following proposal to work:
Proposed spec changes:
I propose that the rules for handling ciphersuites at the server side
become the following:
If the ciphersuites in the ClientHello contains no ciphers other than
the following[*], they indicate that the Tor v1 link protocol is in use.
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
If the advertised ciphersuites in the ClientHello are _exactly_[*]
the following, they indicate that the Tor v2+ link protocol is in
use, AND that the ClientHello may have unsupported ciphers. In this
case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or
DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher.
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.
Otherwise, the ClientHello has these semantics: The inclusion of any
cipher supported by OpenSSL 1.0.0 means that the client supports it,
with the exception of
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
which is never supported. Clients MUST advertise support for at least one of
TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
The server MUST choose a ciphersuite with ephemeral keys for forward
secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT
choose any cipher other than AES or 3DES.
Discussion and consequences:
Currently, OpenSSL 1.0.0 (in its default configuration) supports every
cipher that we would need in order to give the same list as Firefox
versions 8 through 11 give in their default configuration, with the
exception of the FIPS ciphersuite above. Therefore, we will be able
to fake the new ciphersuite list correctly in all of our bundles that
include OpenSSL, and on every version of Unix that keeps up-to-date.
However, versions of Tor compiled to use older versions of OpenSSL, or
versions of OpenSSL with some ciphersuites disabled, will no
longer give the same ciphersuite lists as other versions of Tor. On
these platforms, Tor clients will no longer impersonate Firefox.
Users who need to do so will have to download one of our bundles, or
use a non-system OpenSSL.
The proposed spec change above tries to future-proof ourselves by not
declaring that we support every declared cipher, in case we someday
need to handle a new Firefox version. If a new Firefox version
comes out that uses ciphers not supported by OpenSSL 1.0.0, we will
need to define whether clients may advertise its ciphers without
supporting them; but existing servers will continue working whether
we decide yes or no.
The restriction to "servers SHOULD only pick AES or 3DES" is meant to
reflect our current behavior, not to represent a permanent refusal to
support other ciphers. We can revisit it later as appropriate, if for
some bizarre reason Camellia or Seed or Aria becomes a better bet than
AES.
Open questions:
Should the client drop connections if the server chooses a bad
cipher, or a suite without forward secrecy?
Can we get OpenSSL to support the dubious FIPS suite excluded above,
in order to remove a distinguishing opportunity? It is not so simple
as just editing the SSL_CIPHER list in s3_lib.c, since the nonstandard
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher is (IIUC) defined to use the
TLS1 KDF, while declaring itself to be an SSL cipher (!).
Can we do anything to eventually allow the IE7+[**] cipher list as
well? IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current
Tor servers, which _only_ support those. It looks like the only
forward-secure ciphersuites that IE7+ *does* support are ECDHE ones,
and DHE+DSS ones. So if we want this flexibility, we could mandate
server-side ECDHE, or somehow get DHE+DSS support (which would play
havoc with our current certificate generation code IIUC), or say that
it is sometimes acceptable to have a non-forward-secure link
protocol[***]. None of these answers seems like a great one. Is one
best? Are there other options?
[**] Actually, I think it's the Windows SChannel cipher list we
should be looking at here.
[***] If we did _that_, we'd want to specify that CREATE_FAST could
never be used on a non-forward-secure link. Even so, I don't like the
implications of leaking cell types and circuit IDs to a future
compromise.