1
00:00:00,000 --> 00:00:14,820
33C3 preroll music
2
00:00:14,820 --> 00:00:20,190
Herald: Basically the upcoming
talk is about “Deploying TLS 1.3”
3
00:00:20,190 --> 00:00:23,509
and is by Filippo Valsorda
and Nick Sullivan,
4
00:00:23,509 --> 00:00:26,989
and they’re both with Cloudflare.
5
00:00:26,989 --> 00:00:32,110
So please, a warm welcome
to Nick and Filippo!
6
00:00:32,110 --> 00:00:39,490
applause
7
00:00:39,490 --> 00:00:43,820
Filippo: Hello everyone. Alright,
we are here to talk about TLS 1.3.
8
00:00:43,820 --> 00:00:48,340
TLS 1.3 is of course the latest
version of TLS, which stands for
9
00:00:48,340 --> 00:00:52,960
‘Transport Layer Security’.
Now, you might know it best
10
00:00:52,960 --> 00:00:57,900
as, of course, the green lock in
the browser, or by its old name SSL,
11
00:00:57,900 --> 00:01:02,510
which we are still trying
to kill. Now. TLS is
12
00:01:02,510 --> 00:01:07,890
a transparent security protocol
that can tunnel securely
13
00:01:07,890 --> 00:01:12,460
arbitrary application traffic.
It’s used by web browsers, of course,
14
00:01:12,460 --> 00:01:16,760
it’s used by mail servers to
communicate with each other
15
00:01:16,760 --> 00:01:22,270
to secure SMTP. It’s used by
Tor nodes to talk to each other.
16
00:01:22,270 --> 00:01:26,810
But it evolved over 20 years,
17
00:01:26,810 --> 00:01:31,320
but at its core it’s about a client
and a server that want to communicate
18
00:01:31,320 --> 00:01:36,119
securely over the network.
To communicate securely over the network
19
00:01:36,119 --> 00:01:41,170
they need to establish some key material,
to agree on some key material
20
00:01:41,170 --> 00:01:47,349
on the two sides to encrypt
the rest of the traffic.
21
00:01:47,349 --> 00:01:51,989
Now how they agree on this key material
is [done] in a phase that we call
22
00:01:51,989 --> 00:01:57,890
the ‘handshake’. The handshake involves
some public key cryptography and some data
23
00:01:57,890 --> 00:02:02,670
being shovelled from the client to the
server, from the server to the client.
24
00:02:02,670 --> 00:02:07,170
Now this is how the handshake
looks like in TLS 1.2.
25
00:02:07,170 --> 00:02:12,790
So the client starts the dances
by sending a ‘Client Hello’ over,
26
00:02:12,790 --> 00:02:18,960
which specifies what supported
parameters it can use.
27
00:02:18,960 --> 00:02:23,430
The server receives that and sends
a message of its own, which is
28
00:02:23,430 --> 00:02:28,200
‘Server Hello’ that says: “Sure!
Let’s use this cipher suite over here
29
00:02:28,200 --> 00:02:33,230
that you say you support, and
here is my key share to be used
30
00:02:33,230 --> 00:02:39,270
in this key agreement algorithm.
And also here is a certificate
31
00:02:39,270 --> 00:02:45,300
which is signed by an authority
that proves that I am indeed
32
00:02:45,300 --> 00:02:50,370
Cloudflare.com. And here is a signature
from the certificate to prove that
33
00:02:50,370 --> 00:02:55,450
this key share is actually the one that
I want you to use, to establish keys”.
34
00:02:55,450 --> 00:03:00,940
The client receives that, and it generates
its own key share, its own half
35
00:03:00,940 --> 00:03:06,200
of the Diffie-Hellman key exchange,
and sends over the key share,
36
00:03:06,200 --> 00:03:10,999
and a message to say: “Alright, this
is it. This wraps up the handshake”
37
00:03:10,999 --> 00:03:15,490
which is called the ‘Finished’ message.
[The] server receives that, makes
38
00:03:15,490 --> 00:03:20,679
a ‘Finished’ message of its own,
and answers with that. So.
39
00:03:20,679 --> 00:03:25,930
Now we can finally send application
data. So to recap, we went:
40
00:03:25,930 --> 00:03:30,022
Client –> Server, Server –> Client;
Client –> Server, Server –> Client.
41
00:03:30,022 --> 00:03:34,960
We had to do 2 round trips between the
client and the server before we could do
42
00:03:34,960 --> 00:03:40,730
anything. We haven’t sent any
byte on the application layer
43
00:03:40,730 --> 00:03:46,010
until now. Now of course
this, on mobile networks
44
00:03:46,010 --> 00:03:50,539
or in certain parts of the
world, can build up
45
00:03:50,539 --> 00:03:55,320
to hundreds of milliseconds of latency.
And this is what needs to happen
46
00:03:55,320 --> 00:04:00,930
every time a new connection is set up.
Every time the client and the server
47
00:04:00,930 --> 00:04:06,490
have to go twice between them
to establish the keys before
48
00:04:06,490 --> 00:04:12,730
the connection can actually
be used. Now, TLS 1.1
49
00:04:12,730 --> 00:04:17,950
and 1.0 were not that different
from 1.2. So you might ask: well, then
50
00:04:17,950 --> 00:04:23,750
why are we having an entire talk on
TLS 1.3, which is probably just this other
51
00:04:23,750 --> 00:04:31,430
iteration over the same concept? Well,
TLS 1.3 is actually a big re-design.
52
00:04:31,430 --> 00:04:36,740
And in particular, the handshake has been
restructured. And the most visible result
53
00:04:36,740 --> 00:04:43,139
of this is that an entire round
trip has been shaved off.
54
00:04:43,139 --> 00:04:48,929
So, here is how a TLS 1.3
handshake looks like.
55
00:04:48,929 --> 00:04:53,479
How does 1.3 remove a round trip?
How can it do that? Well, it does that
56
00:04:53,479 --> 00:04:59,799
by predicting what key agreement algorithm
57
00:04:59,799 --> 00:05:04,740
the server will decide to use, and
sending pre-emptively a key share
58
00:05:04,740 --> 00:05:10,029
for that algorithm to the server.
So with the first flight we had
59
00:05:10,029 --> 00:05:15,529
the ‘Client Hello’, the supported
parameters, and a key share
60
00:05:15,529 --> 00:05:21,549
for the one that the client thinks the
server will like. The server receives that
61
00:05:21,549 --> 00:05:27,239
and if everything goes well, it will
go like “Oh! Sure! I like this key share.
62
00:05:27,239 --> 00:05:32,789
Here is my own key share to run
the same algorithm, and here is
63
00:05:32,789 --> 00:05:37,719
the other parameters we should use.”
It immediately mixes the two key shares
64
00:05:37,719 --> 00:05:42,319
to get a shared key, because now
it has both key shares – the client’s
65
00:05:42,319 --> 00:05:47,089
and the server’s – and sends again
the certificate and a signature
66
00:05:47,089 --> 00:05:51,339
from the certificate, and then
immediately sends a ‘Finished’ message
67
00:05:51,339 --> 00:05:56,339
because it doesn’t need anything else
from the client. The client receives that,
68
00:05:56,339 --> 00:06:02,020
takes the key share, mixes the shared key
and sends its own ‘Finished’ message,
69
00:06:02,020 --> 00:06:07,009
and is ready to send whatever application
layer data it was waiting to send.
70
00:06:07,009 --> 00:06:12,650
For example your HTTP
request. Now we went:
71
00:06:12,650 --> 00:06:15,919
Client –> Server, Server –> Client.
72
00:06:15,919 --> 00:06:21,330
And we are ready to send data at the
application layer. So you are trying
73
00:06:21,330 --> 00:06:27,239
to setup a HTTPS connection
and your browser
74
00:06:27,239 --> 00:06:32,769
doesn’t need to wait 4x
the latency, or 4x the ping.
75
00:06:32,769 --> 00:06:38,929
It only has to wait 2x. And of course
this saves hundreds of milliseconds
76
00:06:38,929 --> 00:06:46,199
of latency when setting up fresh
connections. Now, this is the happy path.
77
00:06:46,199 --> 00:06:52,299
So this is what happens when the
prediction is correct and the server likes
78
00:06:52,299 --> 00:06:58,449
the client key share. If the server
doesn’t support the key share
79
00:06:58,449 --> 00:07:05,169
that the client sent it will send a polite
request to use a different algorithm
80
00:07:05,169 --> 00:07:10,530
that the client said it can support. We
call that message ‘Hello Retry Request’.
81
00:07:10,530 --> 00:07:16,469
It has a cookie, so that can be stateless,
but essentially it makes a fall-back
82
00:07:16,469 --> 00:07:21,970
to what is effectively a TLS-1.2-like
handshake. And it’s not that hard
83
00:07:21,970 --> 00:07:26,939
to implement because the client follows up
with a new ‘Client Hello’ which looks
84
00:07:26,939 --> 00:07:34,489
essentially exactly like a fresh one. Now.
85
00:07:34,489 --> 00:07:42,179
Here I’ve been lying to you.
TLS 1.2 is not always 2 round trips.
86
00:07:42,179 --> 00:07:47,779
Most of the connections we see from the
Cloudflare edge e.g. are ‘resumptions’.
87
00:07:47,779 --> 00:07:53,299
That means that the client has connected
to that website before in the past.
88
00:07:53,299 --> 00:07:59,079
And we can use that, we can exploit
that to make the handshake faster.
89
00:07:59,079 --> 00:08:06,290
That means that the client can remember
something about the key material
90
00:08:06,290 --> 00:08:10,959
to make the next connection
a round trip even in TLS 1.2.
91
00:08:10,959 --> 00:08:16,019
So here is how it looks like. Here
you have your normal TLS 1.2 full
92
00:08:16,019 --> 00:08:22,479
2-round trip connection. And over
here it sends a new session ticket.
93
00:08:22,479 --> 00:08:30,029
A session ticket is nothing else than a
encrypted wrapped blob of key material
94
00:08:30,029 --> 00:08:35,100
that the client will hold on to. The
session ticket is encrypted and signed
95
00:08:35,100 --> 00:08:40,039
with a key that only the server knows.
So it’s completely opaque to the client.
96
00:08:40,039 --> 00:08:45,040
But the client will keep it together
with the key material of the connection,
97
00:08:45,040 --> 00:08:49,340
so that the next time it makes
a connection to that same website
98
00:08:49,340 --> 00:08:54,439
it will send a ‘Client Hello’,
and a session ticket.
99
00:08:54,439 --> 00:08:59,180
If the server recognises the session
ticket it will decrypt it, find inside
100
00:08:59,180 --> 00:09:04,090
the key material. And now, after only one
round trip, the server will have some
101
00:09:04,090 --> 00:09:09,820
shared key material with the client because
the client held on to the key material
102
00:09:09,820 --> 00:09:15,460
from last time and the server just
decrypted it from the session ticket.
103
00:09:15,460 --> 00:09:20,890
OK? So now the server has some shared
keys to use already, and it sends
104
00:09:20,890 --> 00:09:26,150
a ‘Finished’ message, and the client sends
its own ‘Finished’ message and the request.
105
00:09:26,150 --> 00:09:31,550
So this is TLS 1.2. This is what
is already happening every day
106
00:09:31,550 --> 00:09:37,380
with most modern TLS connections. Now.
107
00:09:37,380 --> 00:09:43,530
TLS 1.3 resumption is not that different.
It still has the concept of a session ticket.
108
00:09:43,530 --> 00:09:48,300
We changed the name of what’s inside
the session ticket to a ‘PSK’ but that
109
00:09:48,300 --> 00:09:53,220
just means ‘Pre-shared Key’ because
that’s what it is: it’s some key material
110
00:09:53,220 --> 00:09:58,480
that was agreed upon in advance.
And it works the same way:
111
00:09:58,480 --> 00:10:02,830
the server receives the session
ticket, decrypts it and jumps to the
112
00:10:02,830 --> 00:10:07,450
‘Finished’ message. Now,
113
00:10:07,450 --> 00:10:13,070
a problem with resumption
is that if an attacker
114
00:10:13,070 --> 00:10:17,130
controls the session ticket key
– the key that the server uses
115
00:10:17,130 --> 00:10:21,540
to encrypt the session ticket that
has inside the key material –
116
00:10:21,540 --> 00:10:27,050
an attacker can passively or in the future
even, with a recording of the connection,
117
00:10:27,050 --> 00:10:33,460
decrypt the session ticket from the
‘Client Hello’, find the PSK inside it
118
00:10:33,460 --> 00:10:38,320
and use it to decrypt the rest of
the connection. This is not good.
119
00:10:38,320 --> 00:10:42,519
This means that someone can do
passive decryption by just having
120
00:10:42,519 --> 00:10:47,819
the session ticket key. How this is
addressed usually is that we say
121
00:10:47,819 --> 00:10:52,540
that session ticket keys are short-
lived. But still it would be nice if
122
00:10:52,540 --> 00:10:56,270
we didn’t have to rely on that. And there
are actually nice papers that tell us
123
00:10:56,270 --> 00:11:01,310
that implementations don’t
always do this right. So,
124
00:11:01,310 --> 00:11:07,050
instead what TLS 1.3 allows
us to do is use Diffie-Hellman
125
00:11:07,050 --> 00:11:11,760
with resumption. In 1.2 there
was no way to protect
126
00:11:11,760 --> 00:11:16,720
against session ticket key
compromise. In 1.3 what you can do
127
00:11:16,720 --> 00:11:21,409
is send a key share as part
of the ‘Client Hello’ anyway,
128
00:11:21,409 --> 00:11:25,499
and the server will send a key share
together with the ‘Server Hello’,
129
00:11:25,499 --> 00:11:31,710
and they will run Diffie-Hellman.
Diffie-Hellman is what was used to
130
00:11:31,710 --> 00:11:36,009
introduce forward secrecy against
the compromise of, for example,
131
00:11:36,009 --> 00:11:41,339
the certificate private key in 1.2, and
it’s used here to provide forward secrecy
132
00:11:41,339 --> 00:11:46,290
for resumed connections.
Now, you will say:
133
00:11:46,290 --> 00:11:51,240
“Now this looks essentially
like a normal 1.3 handshake,
134
00:11:51,240 --> 00:11:55,770
why having the PSK at all?” Well,
there is something missing from this one,
135
00:11:55,770 --> 00:11:59,510
there is no certificate. Because
there is no need to re-authenticate
136
00:11:59,510 --> 00:12:04,620
with a certificate because the client and
the server spoke in the past, and so
137
00:12:04,620 --> 00:12:09,099
the client knows that it already checked
the certificate of the server and
138
00:12:09,099 --> 00:12:12,819
if the server can decrypt the session
ticket it means that it’s actually
139
00:12:12,819 --> 00:12:17,879
who it says it is. So, the two
key shares get mixed together.
140
00:12:17,879 --> 00:12:22,860
Then mixed with the PSK to make
a key that encrypts the rest
141
00:12:22,860 --> 00:12:29,580
of the connection. Now.
There is one other feature
142
00:12:29,580 --> 00:12:34,701
that is introduced by TLS 1.3
resumption. And that is the fact
143
00:12:34,701 --> 00:12:40,830
that it allows us to make 0-round
trip handshakes. Again,
144
00:12:40,830 --> 00:12:47,280
all handshakes in 1.3
are mostly 1-round trip.
145
00:12:47,280 --> 00:12:52,140
TLS 1.2 resumptions can be
at a minimum 1-round trip.
146
00:12:52,140 --> 00:12:58,331
TLS 1.3 resumptions can be 0-round
trip. How does a 0-round trip
147
00:12:58,331 --> 00:13:04,210
handshake work? Well, if you think about
it, when you start, you have a PSK,
148
00:13:04,210 --> 00:13:10,119
a Pre-Shared Key. The client
can just use that to encrypt
149
00:13:10,119 --> 00:13:15,680
this early data that it wants to
send to the server. So the client
150
00:13:15,680 --> 00:13:20,439
opens a connection, to a server that it
has already connected to in the past,
151
00:13:20,439 --> 00:13:25,349
and sends ‘Client Hello’, session ticket,
152
00:13:25,349 --> 00:13:29,920
key share for Diffie-Hellman and
then early data. Early data is
153
00:13:29,920 --> 00:13:34,410
this blob of application data
– it can be e.g. a HTTP request –
154
00:13:34,410 --> 00:13:39,409
encrypted with the PSK.
The server receives this,
155
00:13:39,409 --> 00:13:45,369
decrypts the session ticket, finds
the PSK, uses the PSK to decrypt the
156
00:13:45,369 --> 00:13:50,770
early data and then proceeds as normal:
mixes the 2 key shares, mixes the PSK in,
157
00:13:50,770 --> 00:13:55,270
makes a new key for the rest of the
connection and continues the connection.
158
00:13:55,270 --> 00:14:00,289
So what happened here? We were able to
send application data immediately upon
159
00:14:00,289 --> 00:14:05,339
opening the connection. This means that
we completely removed the performance
160
00:14:05,339 --> 00:14:11,320
overhead of TLS. Now.
161
00:14:11,320 --> 00:14:16,460
0-RTT handshakes, though, have
2 caveats that are theoretically
162
00:14:16,460 --> 00:14:22,540
impossible to remove. One is that
that nice thing that we introduced
163
00:14:22,540 --> 00:14:27,829
with the PSK ECDHE mode, the one where
we do Diffie-Hellman for resumption
164
00:14:27,829 --> 00:14:33,040
in 1.3, does not help with 0-RTT data.
165
00:14:33,040 --> 00:14:38,620
We do Diffie-Hellman when we
reach the green box in the slide.
166
00:14:38,620 --> 00:14:44,000
Of course the early data is only encrypted
with the PSK. So let’s think about
167
00:14:44,000 --> 00:14:49,150
the attacker again. The attacker somehow
stole our session ticket encryption keys.
168
00:14:49,150 --> 00:14:54,969
It can look at the ‘Client Hello’, decrypt
the session ticket, get the PSK out,
169
00:14:54,969 --> 00:15:00,029
use the PSK to decrypt the early data.
170
00:15:00,029 --> 00:15:05,350
And it can do this even from a recording
if it gets the session ticket later on.
171
00:15:05,350 --> 00:15:11,519
So the early data is not forward secret
with respect to the session ticket keys.
172
00:15:11,519 --> 00:15:16,679
Then of course it becomes useless
if we are doing Diffie-Hellman to get
173
00:15:16,679 --> 00:15:23,020
the server answer. That’s only useful
for the first flight sent from the client.
174
00:15:23,020 --> 00:15:28,340
So to recap, a lot of things
going on here: TLS 1.2
175
00:15:28,340 --> 00:15:33,379
introduced forward secrecy
against the compromise of the
176
00:15:33,379 --> 00:15:39,119
certificate private keys, a long
time ago, by using ECDHE modes.
177
00:15:39,119 --> 00:15:45,030
So 1.2 connections can be
always forward secret against
178
00:15:45,030 --> 00:15:50,300
certificate compromise.
TLS 1.3 has that always on as well.
179
00:15:50,300 --> 00:15:55,090
There is no mode that is not forward
secret against compromise of the
180
00:15:55,090 --> 00:16:01,279
certificate. But when we think about what
might happen to the session ticket key:
181
00:16:01,279 --> 00:16:06,000
TLS 1.2 never provides forward secrecy.
182
00:16:06,000 --> 00:16:11,149
In TLS 1.2 compromising the session
ticket key always means being able
183
00:16:11,149 --> 00:16:15,819
to passively and in the future
decrypt resumed connections.
184
00:16:15,819 --> 00:16:22,689
In 1.3 instead, if we use PSK
ECDHE only the early data
185
00:16:22,689 --> 00:16:28,270
can be decrypted by using
the session ticket key alone.
186
00:16:28,270 --> 00:16:33,199
Now, I said that there were 2 caveats.
187
00:16:33,199 --> 00:16:39,329
The second caveat is that
0-RTT data can be replayed.
188
00:16:39,329 --> 00:16:45,449
The scenario is this: you have
some data in the early data
189
00:16:45,449 --> 00:16:51,709
that is somehow authenticated. It might be
a HTTP request with some cookies on it.
190
00:16:51,709 --> 00:16:58,070
And that HTTP request is somehow
executing a transaction,
191
00:16:58,070 --> 00:17:03,150
okay? Moving some money, instructing
the server to do something. An attacker
192
00:17:03,150 --> 00:17:07,580
wants to make that happen multiple
times. It can’t decrypt it, of course
193
00:17:07,580 --> 00:17:13,149
– it’s protected with TLS. So it
can’t read the cookie, and it can’t
194
00:17:13,149 --> 00:17:17,689
modify it because, of course, it’s
protected with TLS. But it can record
195
00:17:17,689 --> 00:17:23,069
the encrypted message
and it can then replay it
196
00:17:23,069 --> 00:17:27,900
against the server. Now if you have
a single server this is easy to fix.
197
00:17:27,900 --> 00:17:32,520
You just take a note of the messages you
have seen before and you just say like
198
00:17:32,520 --> 00:17:37,500
“No, this looks exactly like something I
got before”. But if, for example like
199
00:17:37,500 --> 00:17:42,270
Cloudflare you are running multiple data
centres around the world, you cannot keep
200
00:17:42,270 --> 00:17:47,650
consistent state all the time, in real
time across all machines. So there would
201
00:17:47,650 --> 00:17:52,370
be different machines that if they
receive this message will go like
202
00:17:52,370 --> 00:17:57,530
“Sure I have the session ticket key,
I decrypt the PSK, I use the PSK,
203
00:17:57,530 --> 00:18:02,080
I decrypt the early data, I find
inside something, I execute what
204
00:18:02,080 --> 00:18:07,510
it tells me to do.” Now, of
course, this is not desirable.
205
00:18:07,510 --> 00:18:13,010
One countermeasure that TLS offers
is that the client sends a value
206
00:18:13,010 --> 00:18:18,689
in that bundle which is how long
ago in milliseconds I obtained
207
00:18:18,689 --> 00:18:23,790
the session ticket. The server
looks at that value and
208
00:18:23,790 --> 00:18:29,080
if it does not match its own view of this
information it will reject the message.
209
00:18:29,080 --> 00:18:34,020
That means that if the attacker records
the message and then 10 seconds later
210
00:18:34,020 --> 00:18:40,000
tries to replay it the times won’t
match and the server can drop it.
211
00:18:40,000 --> 00:18:44,510
But this is not a full solution because
if the attacker is fast enough
212
00:18:44,510 --> 00:18:50,369
it can still replay messages.
So, everything the server can do
213
00:18:50,369 --> 00:18:55,970
is either accept the
0-RTT data, or reject it.
214
00:18:55,970 --> 00:19:00,570
It can’t just take some part of it or
take a peek and then decide because
215
00:19:00,570 --> 00:19:05,540
it’s the ‘Server Hello’ message that
says whether it’s accepted or rejected.
216
00:19:05,540 --> 00:19:09,759
And the client will keep sending early
data until it gets the ‘Server Hello’.
217
00:19:09,759 --> 00:19:15,960
There’s a race here. So the server has to
go blind and decide “Am I taking 0-RTT data
218
00:19:15,960 --> 00:19:20,990
or am I just rejecting it all?” If it’s
taking it, and then it finds out that it’s
219
00:19:20,990 --> 00:19:26,750
something that it can’t process because
“Oh god, there is a HTTP POST in here
220
00:19:26,750 --> 00:19:32,470
that says to move some money, I can’t
do this unless I know it’s not replayed.”
221
00:19:32,470 --> 00:19:37,060
So the server has to get some
confirmation. The good news is that
222
00:19:37,060 --> 00:19:40,600
if the server waits for the ‘Finished’
message… The server sends
223
00:19:40,600 --> 00:19:45,280
the ‘Server Hello’, the ‘Finished’
and waits for the client’s one.
224
00:19:45,280 --> 00:19:51,050
When the client’s one gets there it means
that also the early data was not replayed,
225
00:19:51,050 --> 00:19:54,950
because that ‘Finished’ message
ties together the entire handshake
226
00:19:54,950 --> 00:19:59,769
together with some random value that
the server sent. So it’s impossible
227
00:19:59,769 --> 00:20:04,380
that it was replayed. So, this is
what a server can do: it can accept
228
00:20:04,380 --> 00:20:08,780
the early data and if it’s something
that is not idempotent, something
229
00:20:08,780 --> 00:20:14,610
that is dangerous, if it’s replayed it
can just wait for the confirmation.
230
00:20:14,610 --> 00:20:18,850
But that means it has to buffer it, and
there’s a risk for an attack here, where
231
00:20:18,850 --> 00:20:25,580
an attacker just sends a HTTP POST, with
a giant body just to fill your memory.
232
00:20:25,580 --> 00:20:31,840
So what we realised is that we could help
with this if we wrote on the session tickets
233
00:20:31,840 --> 00:20:37,240
what’s the maximum amount of
early data that the client can send.
234
00:20:37,240 --> 00:20:41,500
If we see someone sending more than
that, then it’s an attacker and we
235
00:20:41,500 --> 00:20:47,499
close the connection, drop the
buffer, free up the memory.
236
00:20:47,499 --> 00:20:52,969
But. Anyway. However
countermeasures we deploy,
237
00:20:52,969 --> 00:20:58,780
unless we can keep global state across the
servers, we have to inform the application
238
00:20:58,780 --> 00:21:03,429
that “this data might be replayed”.
The spec knows this.
239
00:21:03,429 --> 00:21:08,150
So the TLS 1.3 spec EXPLICITLY says
240
00:21:08,150 --> 00:21:14,420
protocols must NOT use
0-RTT without a profile
241
00:21:14,420 --> 00:21:19,159
that defines its use. Which means
“without knowing what they are doing”.
242
00:21:19,159 --> 00:21:24,419
This means that TLS stack
API’s have to do 1 round trip
243
00:21:24,419 --> 00:21:30,360
by default, which is not affected by
replays, and then allow the server
244
00:21:30,360 --> 00:21:35,571
to call some API’s to either reject
or wait for the confirmation,
245
00:21:35,571 --> 00:21:41,470
and to let the client decide what goes
into this dangerous re-playable
246
00:21:41,470 --> 00:21:46,040
piece of data. So this will change
247
00:21:46,040 --> 00:21:49,840
based on the protocols but what about
our favourite protocol? What about
248
00:21:49,840 --> 00:21:55,329
HTTP? Now HTTP should
be easy, the HTTP spec,
249
00:21:55,329 --> 00:22:00,759
you go read it and it says “Well,
GET requests are idempotent,
250
00:22:00,759 --> 00:22:06,149
they must not change anything on the
server”. Solved! We will just allow
251
00:22:06,149 --> 00:22:10,670
GET requests in early data because even
if they are replayed nothing happened!
252
00:22:10,670 --> 00:22:16,640
Yay! Nope. sighs You will definitely
find some server on the internet
253
00:22:16,640 --> 00:22:23,020
that has something like
“send-money.php?to=filippo&amount=this”
254
00:22:23,020 --> 00:22:28,870
and it’s a GET request. And if an attacker
records this, which is early data,
255
00:22:28,870 --> 00:22:33,510
and then replays this against a different
server in the pool, that will get executed
256
00:22:33,510 --> 00:22:38,780
twice. And we can’t have that.
257
00:22:38,780 --> 00:22:43,300
Now, so what can we do here?
258
00:22:43,300 --> 00:22:46,890
We make trade-offs!
259
00:22:46,890 --> 00:22:51,779
If you know your application, you can
make very specific trade-offs. E.g.
260
00:22:51,779 --> 00:22:57,020
Google has been running QUIC
with 0-RTT for the longest time,
261
00:22:57,020 --> 00:23:02,200
for 3 years I think? And that means that
they know very well their application.
262
00:23:02,200 --> 00:23:07,419
And they know that they don’t have
any “send-money.php” endpoints.
263
00:23:07,419 --> 00:23:12,710
But if you are like Cloudflare that
fronts a wide number of applications
264
00:23:12,710 --> 00:23:17,720
you can’t make such wide sweeping
assumptions, and you have instead
265
00:23:17,720 --> 00:23:22,570
to hope for some middle ground. For
example, something we might decide to do
266
00:23:22,570 --> 00:23:28,730
is to only allow GETs
to the root. So “GET /”
267
00:23:28,730 --> 00:23:33,200
which might be the most benefit because
maybe most connections start like that,
268
00:23:33,200 --> 00:23:38,710
and the least likely to cause trouble.
269
00:23:38,710 --> 00:23:43,140
We are still working on how exactly to
bring this to applications. So if you know
270
00:23:43,140 --> 00:23:48,199
of an application that would get hurt
by something as simple as that
271
00:23:48,199 --> 00:23:53,840
do email us, but actually,
if you have an application
272
00:23:53,840 --> 00:23:59,160
that is that vulnerable I have
bad news. Thai Duong et. al.
273
00:23:59,160 --> 00:24:04,150
demonstrated that browsers will
today, without TLS 1.3 or anything,
274
00:24:04,150 --> 00:24:09,740
replay HTTP requests
if network errors happen.
275
00:24:09,740 --> 00:24:15,670
And they will replay them silently.
So it might not be actually worse
276
00:24:15,670 --> 00:24:21,990
than the current state. Okay.
I can actually see everyone
277
00:24:21,990 --> 00:24:27,959
getting uneasy in their seats, thinking
“There the cryptographers are at it again!
278
00:24:27,959 --> 00:24:32,740
They are making the security protocol that
we need more complex than it has to be
279
00:24:32,740 --> 00:24:38,889
to get their job security for
the next 15 years!” Right?
280
00:24:38,889 --> 00:24:44,479
No. No. I can actually assure you that
281
00:24:44,479 --> 00:24:49,709
one of the big changes, in my opinion
even bigger than the round trips in 1.3,
282
00:24:49,709 --> 00:24:54,770
is that everything is being weighted
for the benefit against the complexity
283
00:24:54,770 --> 00:24:59,180
that it introduces. And
while 0-RTT made the cut
284
00:24:59,180 --> 00:25:02,630
most other things definitely didn’t.
285
00:25:02,630 --> 00:25:07,890
Nick: Right. Thanks Filippo.
286
00:25:07,890 --> 00:25:13,640
In TLS 1.3 as an iteration of
TLS we also went back, or,
287
00:25:13,640 --> 00:25:18,120
“we” being the people who are
looking at TLS, went back and
288
00:25:18,120 --> 00:25:22,770
revisited the existing TLS 1.2 features
that sort of seemed reasonable at the time
289
00:25:22,770 --> 00:25:27,439
and decided whether or not the complexity
and the danger added by these features,
290
00:25:27,439 --> 00:25:32,349
or these protocols, or these
primitives involved in TLS were
291
00:25:32,349 --> 00:25:37,739
reasonable to keep. And the big one which
happened early on in the process is
292
00:25:37,739 --> 00:25:43,790
‘Static RSA’ mode. So this is the way that
TLS has been working back since SSL.
293
00:25:43,790 --> 00:25:48,179
Rather than using Diffie-Hellman to
establish a shared key… How this works is,
294
00:25:48,179 --> 00:25:52,320
the client will make its own shared
key, and encrypt it with the server’s
295
00:25:52,320 --> 00:25:56,570
certificate public key which is gonna
be an RSA key, and then just send it
296
00:25:56,570 --> 00:26:00,770
in plain text over the wire to the server.
And then the server would use its
297
00:26:00,770 --> 00:26:04,650
private key to decrypt that, and then
establish a shared key. So the client
298
00:26:04,650 --> 00:26:09,710
creates all the key material in this case.
And one thing that is sort of obvious
299
00:26:09,710 --> 00:26:13,650
from this is that if the private key
for the certificate is comprised,
300
00:26:13,650 --> 00:26:18,149
even after the fact, even years later,
someone with the transcript of what happened
301
00:26:18,149 --> 00:26:23,480
can go back and decrypt this key material,
and then see the entire conversation.
302
00:26:23,480 --> 00:26:28,419
So this was removed very early in the
process, somewhere around 2 years ago
303
00:26:28,419 --> 00:26:33,919
in TLS 1.3. So, much to our surprise,
and the surprise of everyone
304
00:26:33,919 --> 00:26:39,680
reading the TLS mailing
list, just very recently,
305
00:26:39,680 --> 00:26:44,610
near the end of the standardisation
process where TLS 1.3 was almost final
306
00:26:44,610 --> 00:26:50,800
this e-mail landed on the list. And this
is from Andrew Kennedy who works at BITS
307
00:26:50,800 --> 00:26:56,550
which basically means he works
at banks. So this is what he said:
308
00:26:56,550 --> 00:27:01,670
“Deprecation of the RSA key exchange
in TLS 1.3 will cause significant problems
309
00:27:01,670 --> 00:27:06,760
for financial institutions, almost all of
whom are running TLS internally and have
310
00:27:06,760 --> 00:27:12,510
significant, security-critical investments
in out-of-band TLS decryption”.
311
00:27:12,510 --> 00:27:17,810
“Out-of-band TLS decryption”… mmh…
laughs - applause
312
00:27:17,810 --> 00:27:23,490
That certainly sounds critical…
critical for someone, right?
313
00:27:23,490 --> 00:27:26,140
laughs - applause
So…
314
00:27:26,140 --> 00:27:32,200
laughs
applause
315
00:27:32,200 --> 00:27:37,039
So one of the bright spots was
Kenny Paterson’s response to this,
316
00:27:37,039 --> 00:27:41,680
in which he said: “My view
concerning your request: no.
317
00:27:41,680 --> 00:27:44,920
Rationale: We’re trying to build a MORE
secure internet.” The emphasis on ‘more’
318
00:27:44,920 --> 00:27:47,350
is mine but I’m sure he meant it, yeah.
319
00:27:47,350 --> 00:27:54,100
applause
320
00:27:54,100 --> 00:27:58,840
So after this the banking folks came
to the IETF and presented this slide
321
00:27:58,840 --> 00:28:04,460
to describe how hard it was to actually
debug their system. This is a very simple…
322
00:28:04,460 --> 00:28:09,270
I guess, with respect to banking. Those
are the different switches, routers,
323
00:28:09,270 --> 00:28:14,480
middle ware, web applications; and
everything talks TLS one to the other.
324
00:28:14,480 --> 00:28:19,730
And after this discussion we decided
we came to a compromise.
325
00:28:19,730 --> 00:28:24,160
But instead of actually compromising
the protocol Matthew Green
326
00:28:24,160 --> 00:28:28,900
taught them how to use Diffie-Hellman
incorrectly. They ended up actually
327
00:28:28,900 --> 00:28:33,110
being able to do what they wanted
to do, without us – or anybody
328
00:28:33,110 --> 00:28:36,780
in the academic community, or in the
TLS community – adding back this
329
00:28:36,780 --> 00:28:41,720
insecure piece of TLS.
330
00:28:41,720 --> 00:28:45,580
So if you want to read this it shows
how to do it. But in any case
331
00:28:45,580 --> 00:28:49,970
– we didn’t add it back.
Don’t do this, basically! laughs
332
00:28:49,970 --> 00:28:54,300
applause
333
00:28:54,300 --> 00:29:00,100
So we killed static RSA, and
what else did we kill? Well,
334
00:29:00,100 --> 00:29:03,769
looking back on the trade-offs there is
a number of primitives that are in use
335
00:29:03,769 --> 00:29:08,519
in TLS 1.2 and earlier that just
haven’t stood the test of time.
336
00:29:08,519 --> 00:29:12,130
So, RC4 stream cipher. Gone!
applause
337
00:29:12,130 --> 00:29:14,790
3DES (Triple DES) block cipher. Gone!
applause
338
00:29:14,790 --> 00:29:21,529
MD5, SHA1… all gone. Yo!
ongoing applause
339
00:29:21,529 --> 00:29:26,480
There is even constructions that took…
basic block cipher constructions
340
00:29:26,480 --> 00:29:31,640
that are gone: AES-CBC.
Gone. RSA-PKCS1-1.5,
341
00:29:31,640 --> 00:29:36,810
this has been known to have been
problematic since 1998, also gone!
342
00:29:36,810 --> 00:29:41,770
They have also removed several features
like Compression and Renegotiation which
343
00:29:41,770 --> 00:29:47,130
was replaced with a very lightweight
‘key update’ mechanism. So in TLS 1.3
344
00:29:47,130 --> 00:29:52,490
none of these met the balance of
benefit vs. complexity. And a lot of these
345
00:29:52,490 --> 00:29:58,030
vulnerabilities, you might recognize, are
just impossible in TLS 1.3. So that’s good.
346
00:29:58,030 --> 00:30:04,010
applause
347
00:30:04,010 --> 00:30:09,149
So the philosophy for TLS 1.3 in a lot of
places is simplify and make it more robust
348
00:30:09,149 --> 00:30:14,549
as much as possible. There are a number
of little cases in which we did that.
349
00:30:14,549 --> 00:30:18,680
Some of the authors of this paper may be
in the audience right now. But there is
350
00:30:18,680 --> 00:30:24,030
a way in which block ciphers where
used for the actual record layer
351
00:30:24,030 --> 00:30:27,640
that was not as robust as it could be.
It has been replaced with a much simpler
352
00:30:27,640 --> 00:30:32,340
mechanism. TLS 1.2 had this
353
00:30:32,340 --> 00:30:37,520
really kind of funny ‘Catch 22’ in it
where the cipher negotiation
354
00:30:37,520 --> 00:30:41,810
is protected by a ‘Finished’ message which
is a message-authentication code, but
355
00:30:41,810 --> 00:30:47,020
the algorithm for that code was determined
in the cipher negotiation, so,
356
00:30:47,020 --> 00:30:53,090
it had this kind of loop-back effect. And
attacks like FREAK, LogJam and CurveSwap
357
00:30:53,090 --> 00:30:59,300
(from last year) managed to exploit these
to actually downgrade connections.
358
00:30:59,300 --> 00:31:02,669
And this was something that was happening
in the wild. And the reason for this is
359
00:31:02,669 --> 00:31:06,980
that these cipher suites in this handshake
are not actually digitally signed
360
00:31:06,980 --> 00:31:11,649
by the private key. And in TLS 1.3
this was changed. Everything
361
00:31:11,649 --> 00:31:16,129
from the signature up is digitally
signed. So this is great!
362
00:31:16,129 --> 00:31:21,290
What else did we change? Well,
what else did TLS 1.3 change
363
00:31:21,290 --> 00:31:27,860
vs. TLS 1.2? And that is: fewer, better
choices. And in cryptography
364
00:31:27,860 --> 00:31:33,410
better choices always means fewer choices.
So there is now a shortlist of curves and
365
00:31:33,410 --> 00:31:36,920
finite field groups that you can use. And
no arbitrary Diffie-Hellman groups made up
366
00:31:36,920 --> 00:31:41,949
by the server, no arbitrary curves
that can be used. And this sort of
367
00:31:41,949 --> 00:31:47,940
shortening of the list of parameters
really enables 1-RTT to work
368
00:31:47,940 --> 00:31:51,960
a lot of the time. So as Filippo
mentioned, the client has to guess
369
00:31:51,960 --> 00:31:56,540
which key establishment
methods the server supports,
370
00:31:56,540 --> 00:32:01,199
and send that key share. If there is
a short list of only-secure options
371
00:32:01,199 --> 00:32:05,599
this happens a larger percentage of
the time. So when you’re configuring
372
00:32:05,599 --> 00:32:10,760
your TLS server it no longer looks
like a complicated takeout menu,
373
00:32:10,760 --> 00:32:15,690
it’s more like a wedding [menu]. Take one
of each, and it’s a lot more delicious
374
00:32:15,690 --> 00:32:21,970
anyways. And you can look on
Wireshark, it’s also very simple.
375
00:32:21,970 --> 00:32:27,800
The cipher suites use extensions,
the curves, and you can go from there.
376
00:32:27,800 --> 00:32:33,301
Filippo: Now, TLS 1.3 also fixed
what I think was one of the biggest
377
00:32:33,301 --> 00:32:37,441
actual design mistakes of
TLS 1.2. We talked about
378
00:32:37,441 --> 00:32:43,410
how forward secrecy works
with resumption in 1.2 and 1.3.
379
00:32:43,410 --> 00:32:49,199
But TLS 1.2 is even more
problematic. TLS 1.2 wraps
380
00:32:49,199 --> 00:32:55,679
inside the session tickets the actual
master secret of the old connection.
381
00:32:55,679 --> 00:33:02,509
So it takes the actual keys that encrypt
the traffic of the original connection,
382
00:33:02,509 --> 00:33:07,860
encrypts them with the session ticket key,
and sends that to the client to be sent
383
00:33:07,860 --> 00:33:13,619
back the next time. We talked about
how there’s a risk that an attacker will
384
00:33:13,619 --> 00:33:18,139
obtain session ticket keys, and decrypt
the session tickets, and break
385
00:33:18,139 --> 00:33:23,859
the forward secrecy and decrypt
the resumed connections. Well,
386
00:33:23,859 --> 00:33:29,780
in TLS 1.2 it’s even worse. If they
decrypt the session tickets they could
387
00:33:29,780 --> 00:33:35,950
go back and backward decrypt the original
388
00:33:35,950 --> 00:33:42,090
non-resumed connection. And
this is completely unnecessary.
389
00:33:42,090 --> 00:33:46,770
We have hash functions, we have one-way
functions where you put an input in
390
00:33:46,770 --> 00:33:52,990
and you get something that you can’t
go back from. So that’s what 1.3 does.
391
00:33:52,990 --> 00:33:58,579
1.3 derives new keys, fresh
keys for the next connection
392
00:33:58,579 --> 00:34:04,090
and wraps them inside the session ticket
to become the PSK. So even if you
393
00:34:04,090 --> 00:34:09,439
decrypt a 1.3 session ticket
you can then attack
394
00:34:09,439 --> 00:34:13,619
the subsequent connection, and we’ve
seen that you might be able to decrypt
395
00:34:13,619 --> 00:34:18,949
only the early data, or all the connection
depending on what mode it uses. But
396
00:34:18,949 --> 00:34:25,959
you definitely can’t decrypt the
original non-resumed connection.
397
00:34:25,959 --> 00:34:31,729
So, this would be bad enough, but 1.2
makes another decision that entirely
398
00:34:31,729 --> 00:34:36,760
puzzled me. The whole ‘using the master
secret’ might be just because session
399
00:34:36,760 --> 00:34:41,779
tickets were an extension in
1.2, which they are not in 1.3.
400
00:34:41,779 --> 00:34:47,990
But, 1.2 sends the new session
ticket message at the beginning
401
00:34:47,990 --> 00:34:53,490
of the original handshake,
unencrypted! I mean
402
00:34:53,490 --> 00:34:58,670
encrypted with the session ticket keys
but not with the current session keys.
403
00:34:58,670 --> 00:35:04,040
So, any server that just supports
404
00:35:04,040 --> 00:35:10,130
session tickets will have at the
beginning of all connections,
405
00:35:10,130 --> 00:35:14,670
even if resumption never happens, they
will have a session ticket which is
406
00:35:14,670 --> 00:35:18,820
nothing else than the ephemeral
keys of that connection
407
00:35:18,820 --> 00:35:23,400
wrapped with the session
ticket keys. Now, if you are
408
00:35:23,400 --> 00:35:28,620
a global passive adversary
that somehow wants to do
409
00:35:28,620 --> 00:35:33,060
passive dragnet surveillance and
you wanted to passively decrypt
410
00:35:33,060 --> 00:35:38,720
all the connections, and somehow you
were able to obtain session ticket keys,
411
00:35:38,720 --> 00:35:44,350
what you would find at the beginning
of every TLS 1.2 connection is
412
00:35:44,350 --> 00:35:49,830
the session keys encrypted with
the session ticket keys. Now,
413
00:35:49,830 --> 00:35:55,580
1.3 solves this, and in 1.3 this kind
of attacks are completely impossible.
414
00:35:55,580 --> 00:35:59,420
The only thing that you can passively
decrypt, or decrypt after the fact,
415
00:35:59,420 --> 00:36:04,230
is the early data, and definitely not non-
resumed connections, and definitely not
416
00:36:04,230 --> 00:36:10,920
anything that comes after 0-RTT.
417
00:36:10,920 --> 00:36:12,840
Nick: So it’s safer, basically.
laughs
418
00:36:12,840 --> 00:36:15,710
Filippo: Hope so!
Nick: …hopefully.
419
00:36:15,710 --> 00:36:20,670
And how do we know that it’s safer? Well,
these security parameters, and these
420
00:36:20,670 --> 00:36:25,840
security requirements of TLS have been
formalized and, as opposed to earlier
421
00:36:25,840 --> 00:36:30,310
versions of TLS the folks in the academic
community who do formal verification were
422
00:36:30,310 --> 00:36:34,170
involved earlier. So there have been
several papers analyzing the state machine
423
00:36:34,170 --> 00:36:40,120
and analyzing the different modes of
TLS 1.3, and these have aided a lot
424
00:36:40,120 --> 00:36:45,360
in the development
of the protocol. So,
425
00:36:45,360 --> 00:36:50,570
who actually develops TLS 1.3? Well, it’s
426
00:36:50,570 --> 00:36:54,730
an organization called the IETF which is
the Internet Engineering Taskforce. It’s
427
00:36:54,730 --> 00:36:59,760
a group of volunteers that meet 3 times
a year and have mailing lists, and they
428
00:36:59,760 --> 00:37:03,461
debate these protocols endlessly. They
define the protocols that are used
429
00:37:03,461 --> 00:37:07,910
on the internet. And originally, the first
thing that I ever saw about this – this is
430
00:37:07,910 --> 00:37:13,250
a tweet of mine from September
2013 – was a wish list for TLS 1.3.
431
00:37:13,250 --> 00:37:19,920
And since then they came out
with a first draft at the IETF…
432
00:37:19,920 --> 00:37:24,630
Documents that define protocols
are known as RFCs, and
433
00:37:24,630 --> 00:37:29,200
the lead-up to something becoming an RFC
is an ‘Internet Draft’. So you start with
434
00:37:29,200 --> 00:37:34,330
the Internet Draft 0, and then you iterate
on this draft until finally it gets
435
00:37:34,330 --> 00:37:39,980
accepted or rejected as an RFC. So
the first one was almost 3 years ago
436
00:37:39,980 --> 00:37:46,080
back in April 2014, and the current
draft (18) which is considered to be
437
00:37:46,080 --> 00:37:51,590
almost final, it’s in what is
called ‘Last Call’ at the IETF,
438
00:37:51,590 --> 00:37:57,330
was just recently in October.
In the security landscape
439
00:37:57,330 --> 00:38:02,400
during that time you’ve seen so many
different types of attacks on TLS. So:
440
00:38:02,400 --> 00:38:07,860
Triple Handshake, POODLE, FREAK, Logjam,
DROWN (there was a talk about that earlier
441
00:38:07,860 --> 00:38:12,220
today), Lucky Microseconds, SLOTH.
All these different types of acronyms
442
00:38:12,220 --> 00:38:15,550
– you may or may not have heard of –
have happened during the development.
443
00:38:15,550 --> 00:38:21,380
So TLS 1.3 is a living
document, and it’s hopefully
444
00:38:21,380 --> 00:38:27,561
going to be small. I mean,
TLS 1.2 was 79 pages.
445
00:38:27,561 --> 00:38:32,521
It’s kind of a rough read, but
give it a shot! If you like. TLS 1.3
446
00:38:32,521 --> 00:38:36,330
if you shave off a lot of the excess stuff
at the end is actually close. And it’s
447
00:38:36,330 --> 00:38:40,980
a lot nicer read, it’s a lot more precise,
even though there are some interesting
448
00:38:40,980 --> 00:38:46,910
features like 0-RTT, resumption. So
practically, how does it get written?
449
00:38:46,910 --> 00:38:52,810
Well it’s, uh… Github! And a mailing list!
So if you want to send a pull request
450
00:38:52,810 --> 00:38:59,020
to this TLS working group, there it is.
This is actually how the draft gets defined.
451
00:38:59,020 --> 00:39:04,190
And you probably want to send a message
to the mailing list to describe what your
452
00:39:04,190 --> 00:39:09,300
change is, if you want to. I suggest if
anybody wants to be involved this is
453
00:39:09,300 --> 00:39:14,190
pretty late. I mean it’s in ‘Last Call’…
But the mailing list is still open. Now
454
00:39:14,190 --> 00:39:18,370
I’ve been working on this with a bunch of
other people, Filippo as well. We were
455
00:39:18,370 --> 00:39:23,230
contributors on the draft, been working
for over a year on this. You can check
456
00:39:23,230 --> 00:39:29,230
the Github issues to see how much work
has gone into it. The draft has changed
457
00:39:29,230 --> 00:39:34,130
over the years and months.
458
00:39:34,130 --> 00:39:38,620
E.g. Draft 9 had this very
complicated tree structure
459
00:39:38,620 --> 00:39:43,550
for a key schedule, you can see
htk… all these different things
460
00:39:43,550 --> 00:39:49,980
had to do with different keys in the TLS
handshake. And this was inspired by QUIC,
461
00:39:49,980 --> 00:39:55,650
the Google protocol that Filippo mentioned
earlier as well as a paper called ‘OPTLS’.
462
00:39:55,650 --> 00:40:00,610
And it had lots of different modes,
semi-static Diffie-Hellman, and this
463
00:40:00,610 --> 00:40:04,950
tree-based key schedule. And over the
time this was widdled down from this
464
00:40:04,950 --> 00:40:10,510
complicated diagram to what we have
now in TLS 1.3. Which is a very simple
465
00:40:10,510 --> 00:40:16,330
derivation algorithm. This took a lot
of work to get from something big
466
00:40:16,330 --> 00:40:21,670
to something small. But it’s happened!
Other things that happened
467
00:40:21,670 --> 00:40:27,230
in TLS 1.3 are sort of less substantial,
cryptographically, and that involves
468
00:40:27,230 --> 00:40:32,550
naming! If anyone has been following
along, TLS 1.3 is not necessarily
469
00:40:32,550 --> 00:40:38,180
the unanimous choice for the name of this
protocol. It’s, as Filippo mentioned, 1.0,
470
00:40:38,180 --> 00:40:44,000
1.1, 1.2 are pretty small iterations
even on SSLv3, whereas
471
00:40:44,000 --> 00:40:49,071
TLS 1.3 is quite a big change.
So there is a lot of options
472
00:40:49,071 --> 00:40:54,950
for names! Let’s have
a show of hands: Who here
473
00:40:54,950 --> 00:40:59,860
thinks it should be called 1.3?
laughs
474
00:40:59,860 --> 00:41:02,030
Thanks, Filippo! Filippo laughs
Yeah, so, pretty good number.
475
00:41:02,030 --> 00:41:07,840
How about TLS 2? Anybody?
Well, that actually looks like more than…
476
00:41:07,840 --> 00:41:12,940
Filippo: Remember that SSLv2 is
a thing! And it’s a terrible thing!
477
00:41:12,940 --> 00:41:18,040
Nick: You don’t want to confuse
that with us! So how about TLS 4?
478
00:41:18,040 --> 00:41:22,520
Still a significant number of people…
How about TLS 2017? Yeah…
479
00:41:22,520 --> 00:41:25,780
Alright! TLS 7 anybody? Okay…
480
00:41:25,780 --> 00:41:30,400
Filippo: TLS Millennium 2019 X?
481
00:41:30,400 --> 00:41:35,410
YES! Sold!
Nick: Alright! TLS Vista?
482
00:41:35,410 --> 00:41:38,860
laughter - Nick and Filippo laugh
applause
483
00:41:38,860 --> 00:41:44,800
Nick: Lots of options! But just as
a reminder, the rest of the world
484
00:41:44,800 --> 00:41:50,040
doesn’t really call it TLS. This is Google
trends, interest over time, searching for
485
00:41:50,040 --> 00:41:55,300
‘SSL vs. TLS’. SSL is really what most
of the world calls this protocol. So SSL
486
00:41:55,300 --> 00:42:00,240
has the highest version of Version 3,
and that’s kind of the reason why people
487
00:42:00,240 --> 00:42:05,210
thought ‘TLS 4’ was a good idea, because
“Oh, people are confused: 3 is higher
488
00:42:05,210 --> 00:42:10,720
than 1.2, yada-yada-yada”.
489
00:42:10,720 --> 00:42:14,870
This poll was not the only poll. It was
taken there some informal twitter polls.
490
00:42:14,870 --> 00:42:20,030
“Mmm, Bacon!” was a good one,
52% of Ryan Hurst’s poll.
491
00:42:20,030 --> 00:42:23,870
laughter
492
00:42:23,870 --> 00:42:28,130
Versions are a really sticky thing in TLS.
493
00:42:28,130 --> 00:42:32,780
E.g. the versions that we have of TLS
– if you look at them on the wire
494
00:42:32,780 --> 00:42:37,640
they actually don’t match up.
So SSL 3 is 3.0 which does match up.
495
00:42:37,640 --> 00:42:43,720
But TLS 1 is 3.1; 3.2…
TLS 1.2 is 3.3; and originally
496
00:42:43,720 --> 00:42:49,000
I think up to Draft 16
of TLS 1.3 it was 3.4.
497
00:42:49,000 --> 00:42:53,761
Just sort of a bumping the minor
version of TLS 1.2, very confusing.
498
00:42:53,761 --> 00:42:58,511
But after doing some internet
measurement it was determined that
499
00:42:58,511 --> 00:43:02,670
a lot of servers, if you send a ‘Client
Hello’ with ‘3.4’, it just disconnects. So
500
00:43:02,670 --> 00:43:07,960
this is actually really bad, it prevents
browsers from being able to actually
501
00:43:07,960 --> 00:43:13,080
safely downgrade. What a server is
supposed to do if it sees a version
502
00:43:13,080 --> 00:43:18,780
higher than 3.3 is just respond with “3.3”
saying: “Hey, this is the best I have”.
503
00:43:18,780 --> 00:43:24,880
But turns out a lot of these break.
So 3.3 is in the ‘Client Hello’ now, and
504
00:43:24,880 --> 00:43:30,680
3.4 is negotiated as a sub
protocol. So this is messy.
505
00:43:30,680 --> 00:43:35,610
Right? But we do balance the benefits vs.
complexity, and this is one of the ones
506
00:43:35,610 --> 00:43:39,640
where the benefits of not having servers
fail outweigh the complexity added,
507
00:43:39,640 --> 00:43:44,340
of adding an additional thing. And to
prevent this from happening in the future
508
00:43:44,340 --> 00:43:48,820
David Benjamin proposed something called
GREASE where in every single piece of
509
00:43:48,820 --> 00:43:53,920
TLS negotiation you are supposed to,
as a client, add some random stuff
510
00:43:53,920 --> 00:43:56,980
in there, so that servers will
get used to seeing things
511
00:43:56,980 --> 00:44:01,050
that are not versions they’re used to.
So, 0x8a8a. It’s all GREASE-d up!
512
00:44:01,050 --> 00:44:06,320
Filippo: It’s a real thing!
It’s a real very useful thing!
513
00:44:06,320 --> 00:44:08,760
Nick: This is going to be very useful,
for the future, for preventing
514
00:44:08,760 --> 00:44:13,850
these sorts of things. But it’s really
unfortunate that that had to happen.
515
00:44:13,850 --> 00:44:18,830
We are running low on time, but
we dued to actually get involved with
516
00:44:18,830 --> 00:44:23,430
getting our hands dirty. And one thing
the IETF really loves when developing
517
00:44:23,430 --> 00:44:28,680
these standards is running code. So we
started with the IETF 95 Hackathon
518
00:44:28,680 --> 00:44:32,950
which is in April, and managed,
by the end of it, to get Firefox
519
00:44:32,950 --> 00:44:37,740
to load a server hosted by Cloudflare
over TLS 1.3. Which was a big
520
00:44:37,740 --> 00:44:43,250
accomplishment at the time. We used NSS
which is the security library in Firefox
521
00:44:43,250 --> 00:44:48,850
and ‘Mint’ which was a new version
522
00:44:48,850 --> 00:44:52,890
of TLS 1.3, from scratch, written in Go.
523
00:44:52,890 --> 00:44:57,640
And the result was, it worked! But
this was just a proof-of-concept.
524
00:44:57,640 --> 00:45:02,950
Filippo: To build something that was more
production ready, we looked at what was
525
00:45:02,950 --> 00:45:08,330
the TLS library that we were most
confident modifying, which unsurprisingly
526
00:45:08,330 --> 00:45:13,370
wasn’t OpenSSL! So we opted to
527
00:45:13,370 --> 00:45:17,990
build 1.3 on top of the Go
crypto/tls library, which is
528
00:45:17,990 --> 00:45:24,210
in the Go language standard library.
The result, we call it ‘tls-tris’,
529
00:45:24,210 --> 00:45:28,500
and it’s a drop-in replacement for
crypto/tls, and comes with this
530
00:45:28,500 --> 00:45:33,970
wonderful warning that says “Do not use
this for the sake of everything that’s
531
00:45:33,970 --> 00:45:38,990
good and just!” Now, it used to be about
everything, but now it’s not really
532
00:45:38,990 --> 00:45:45,190
about security anymore, we got this
audited, but it’s still about stability.
533
00:45:45,190 --> 00:45:50,510
We are working on upstreaming
this, which will solidify the API,
534
00:45:50,510 --> 00:45:56,000
and you can follow along with the
upstreaming process. The Google people
535
00:45:56,000 --> 00:46:00,830
were kind enough to open us a branch to do
the development, and it will definitely not
536
00:46:00,830 --> 00:46:06,960
hit the next Go release, Go 1.8, but we
are looking forward to upstreaming this.
537
00:46:06,960 --> 00:46:12,010
Anyway, even if you use Go,
deploying is hard.
538
00:46:12,010 --> 00:46:17,800
The first time we deployed Tris
the draft number version was 13.
539
00:46:17,800 --> 00:46:23,630
And to actually support browsers
going forward from there we had
540
00:46:23,630 --> 00:46:29,140
to support multiple draft versions
at the same time by switching on
541
00:46:29,140 --> 00:46:34,590
obscure details sometimes. And sometimes
had to support things that were definitely
542
00:46:34,590 --> 00:46:40,030
not even drafts because
browsers started to… diverge.
543
00:46:40,030 --> 00:46:44,970
Now, anyway, we had
a test matrix that would run
544
00:46:44,970 --> 00:46:50,610
all our commits against all the different
versions of the client libraries,
545
00:46:50,610 --> 00:46:54,980
and that would make sure that we are
always compatible with the browsers.
546
00:46:54,980 --> 00:47:00,170
And these days the clients are actually
much more stable, and indeed
547
00:47:00,170 --> 00:47:05,050
you might be already using it
without knowing. E.g. Chrome Beta,
548
00:47:05,050 --> 00:47:11,160
the beta channel has it enabled for about
50% as an experiment from the Google side.
549
00:47:11,160 --> 00:47:16,110
And this is how our graphs looked
like when we first launched,
550
00:47:16,110 --> 00:47:21,560
when Firefox Nightly enabled it by default
and when Chrome Canary enabled it
551
00:47:21,560 --> 00:47:26,510
by default. These days we are stable,
around 700 requests per second
552
00:47:26,510 --> 00:47:30,640
carried over TLS 1.3.
And on our side we enabled it
553
00:47:30,640 --> 00:47:36,230
for millions of our
websites on Cloudflare.
554
00:47:36,230 --> 00:47:40,830
And, anyway, as we said,
the spec is a living document
555
00:47:40,830 --> 00:47:46,080
and it is open. You can see it on
Github. The Tris implementation is there
556
00:47:46,080 --> 00:47:50,860
even if it has this scary warning, and
the blog here is where we’ll probably
557
00:47:50,860 --> 00:47:56,210
publish all the follow-up research and
results of this. Thank you very much and
558
00:47:56,210 --> 00:47:59,990
if you have any questions please come
forward, I think we have a few minutes.
559
00:47:59,990 --> 00:48:11,770
applause
560
00:48:11,770 --> 00:48:15,690
Herald: Thank you, we have plenty
of time for questions. First question
561
00:48:15,690 --> 00:48:19,770
goes to the Internet.
562
00:48:19,770 --> 00:48:23,930
Signal Angel: The very first
question is of people asking if
563
00:48:23,930 --> 00:48:28,160
the decision of the 0-RTT going
on to the application, handing it
564
00:48:28,160 --> 00:48:32,450
off to the application developers,
if that is a very wise decision?
565
00:48:32,450 --> 00:48:34,130
Filippo: laughs
applause
566
00:48:34,130 --> 00:48:40,230
Filippo: Well… fair. So, as we said, this
is definitely breaking an abstraction.
567
00:48:40,230 --> 00:48:45,500
So it’s NOT broken by default.
If you just update Go
568
00:48:45,500 --> 00:48:50,791
and get TLS 1.3 you won’t
get any 0-RTT because
569
00:48:50,791 --> 00:48:54,800
indeed it requires collaboration by the
application. So unless an application
570
00:48:54,800 --> 00:48:59,980
knows what to do with it it just can not
use that and have all the security benefits
571
00:48:59,980 --> 00:49:06,920
and the one round trip full
handshake advantages, anyway.
572
00:49:06,920 --> 00:49:09,570
Herald: Ok, next question
is from microphone 1.
573
00:49:09,570 --> 00:49:12,680
Question: With your early testing of the
protocol have you been able to capture
574
00:49:12,680 --> 00:49:17,610
any hard numbers on what those
performance improvements look like?
575
00:49:17,610 --> 00:49:21,170
Filippo sighs
576
00:49:21,170 --> 00:49:24,580
Nick: One round trip! laughs
Depends how much a round trip is.
577
00:49:24,580 --> 00:49:28,000
Filippo: Yeah, exactly. One round trip
is… I mean, I can’t tell you a number
578
00:49:28,000 --> 00:49:33,250
because of course if you live in
San Francisco with a fast fiber it’s,
579
00:49:33,250 --> 00:49:39,120
I don’t know, 3 milliseconds, 6…?
If you live in, I don’t know,
580
00:49:39,120 --> 00:49:43,260
some country where EDGE is the only type
of connection you get that’s probably
581
00:49:43,260 --> 00:49:47,700
around one second. I think we have an
average that is around… between 100
582
00:49:47,700 --> 00:49:55,100
and 200 milliseconds, but we haven’t
like formally collected these numbers.
583
00:49:55,100 --> 00:49:57,630
Herald: Ok, next question
from microphone 3.
584
00:49:57,630 --> 00:50:01,720
Question: One remark I wanted to make is
that another improvement that was made
585
00:50:01,720 --> 00:50:07,350
in TLS 1.3 is that they added
encryption to client certificates.
586
00:50:07,350 --> 00:50:11,330
So the client certificates are transmitted
encrypted which is important
587
00:50:11,330 --> 00:50:17,670
if you think about that a client will
move, and a dragnet surveillance entity
588
00:50:17,670 --> 00:50:23,120
could track clients with this. And
another remark/question which might…
589
00:50:23,120 --> 00:50:27,080
Herald: Questions are ended with a question
mark. So can you keep it please a bit short?
590
00:50:27,080 --> 00:50:31,820
Question: Yeah…
That might be stupid so…
591
00:50:31,820 --> 00:50:36,400
Does the fixed Diffie-Hellman
groups… wasn’t that the problem
592
00:50:36,400 --> 00:50:42,890
with the LogJam attack, so… does
this help with LogJam attacks?
593
00:50:42,890 --> 00:50:46,660
Nick: Are you referencing the
proposal for the banks?
594
00:50:46,660 --> 00:50:49,590
Question: No no, just in general,
that you can pre-compute…
595
00:50:49,590 --> 00:50:54,430
Nick: Right, yes, so in Logjam there was
a problem where there was a DH group
596
00:50:54,430 --> 00:50:57,940
that was shared by a lot of different
servers by default. The Apache one,
597
00:50:57,940 --> 00:51:03,800
which was 1024 [bit].
In TLS 1.3 it was restricted to
598
00:51:03,800 --> 00:51:09,190
a pre-computed DH group, that’s
over 2000 bits, as the smallest one,
599
00:51:09,190 --> 00:51:14,600
and even with all the pre-computation in
the world if you have a 2000 bit DH group
600
00:51:14,600 --> 00:51:20,140
it’s not feasible to pre-compute
enough to do any type of attack.
601
00:51:20,140 --> 00:51:21,990
But, yeah, that’s a very good point.
602
00:51:21,990 --> 00:51:24,950
Filippo: …and since they are fixed there
is no way to force the protocol to use
603
00:51:24,950 --> 00:51:28,940
anything else that would not be as strong.
Question: Okay, thanks!
604
00:51:28,940 --> 00:51:32,720
Herald: Next question for microphone 4.
605
00:51:32,720 --> 00:51:37,120
Question: Thanks for your talk! In the
abstract you mentioned that another
606
00:51:37,120 --> 00:51:41,550
feature that had to be killed was SNI,
607
00:51:41,550 --> 00:51:45,920
with the 0-RTT but there are ways to still
implement that, can you elaborate a bit?
608
00:51:45,920 --> 00:51:49,670
Filippo: Yeah. So, we gave this talk
internally twice, and this question came
609
00:51:49,670 --> 00:51:55,590
both of the times. So… laughs
610
00:51:55,590 --> 00:52:01,790
So, SNI is a small parameter
that the client sends to the server
611
00:52:01,790 --> 00:52:06,210
to say which website it is trying to
connect to. E.g. Cloudflare has
612
00:52:06,210 --> 00:52:11,250
a lot of websites behind our machines, so
you have to tell us “Oh I actually want
613
00:52:11,250 --> 00:52:17,230
to connect to blog.filippo.io”. Now
this is of course a privacy concern
614
00:52:17,230 --> 00:52:22,550
because someone just looking at the bytes
on the wire will know what specific website
615
00:52:22,550 --> 00:52:29,450
you want to connect to. Now the unfortunate
thing is that it has the same problem as
616
00:52:29,450 --> 00:52:35,270
getting forward secrecy for the early
data. You send SNI in the ‘Client Hello’,
617
00:52:35,270 --> 00:52:39,620
and at that time you haven’t negotiated
any key yet, so you don’t have anything
618
00:52:39,620 --> 00:52:44,960
to encrypt it with. But if you
don’t send SNI in the first flight
619
00:52:44,960 --> 00:52:49,140
then the server doesn’t know what
certificate to send, so it can’t send
620
00:52:49,140 --> 00:52:53,050
the signature in the first flight! So you
don’t have keys. So you would have to do
621
00:52:53,050 --> 00:52:59,030
a 2-round trip, and now we would
be back at TLS 1.2. So, alas.
622
00:52:59,030 --> 00:53:03,180
That doesn’t work with
1-round trip handshakes.
623
00:53:03,180 --> 00:53:08,820
Nick: That said, there are proposals in
the HTTP2 spec to allow multiplexing,
624
00:53:08,820 --> 00:53:14,210
and this is ongoing work. It could be
possible to establish one connection
625
00:53:14,210 --> 00:53:19,700
to a domain and then establish another
connection within the existing connection.
626
00:53:19,700 --> 00:53:21,950
And that could potentially
protect your SNI.
627
00:53:21,950 --> 00:53:25,520
Filippo: So someone looking would think
that you are going to blog.filippo.io but
628
00:53:25,520 --> 00:53:29,480
then, once you open the connection,
you would be able to ask HTTP2 to also
629
00:53:29,480 --> 00:53:33,200
serve you “this other website”. Thanks!
630
00:53:33,200 --> 00:53:38,170
Herald: Okay, next
question, microphone 7,
631
00:53:38,170 --> 00:53:41,240
or actually 5, sorry.
632
00:53:41,240 --> 00:53:47,440
Question: You mentioned that there
was formal verification of TLS 1.3.
633
00:53:47,440 --> 00:53:54,350
What’s the software that was used
to do the formal verification?
634
00:53:54,350 --> 00:53:59,030
Nick: So there were several software
implementations and protocols…
635
00:53:59,030 --> 00:54:02,650
Let’s see if I can go back… here.
636
00:54:02,650 --> 00:54:06,600
So, Tamarin[Prover] is a piece of software
developed by Cas Cremers and others,
637
00:54:06,600 --> 00:54:11,810
at Oxford and Royal Holloway.
miTLS is in F# I believe,
638
00:54:11,810 --> 00:54:18,430
this is by INRIA.
And NQSB-TLS is in OCAMAL.
639
00:54:18,430 --> 00:54:22,970
So several different languages were used
to develop these and I believe the authors
640
00:54:22,970 --> 00:54:27,490
of NQSB-TLS are here…
641
00:54:27,490 --> 00:54:30,960
Herald: Okay, next question, microphone 8.
642
00:54:30,960 --> 00:54:36,440
Question: Hi! Thanks. Thank you for
your informative presentation.
643
00:54:36,440 --> 00:54:42,690
SSL and TLS history is riddled with “what
could possibly go wrong” ideas and moments
644
00:54:42,690 --> 00:54:48,810
that bit us in the ass eventually. And so
I guess my question is taking into account
645
00:54:48,810 --> 00:54:52,740
that there’s a lot of smaller organisations
or smaller hosting companies etc. that
646
00:54:52,740 --> 00:54:59,600
will probably get this 0-RTT thing
wrong. Your gut feeling? How large
647
00:54:59,600 --> 00:55:04,180
a chance is there that this will indeed
bite us in the ass soon? Thank you.
648
00:55:04,180 --> 00:55:09,990
Filippo: Ok, so, as I said I’m
actually vaguely sceptical
649
00:55:09,990 --> 00:55:16,460
on the impact on HTTP because browsers
can be made to replay requests already.
650
00:55:16,460 --> 00:55:21,610
And we have seen papers
and blog posts about it. But
651
00:55:21,610 --> 00:55:25,830
no one actually went out
and proved that that broke
652
00:55:25,830 --> 00:55:30,620
a huge percent of the internet. But to
be honest, I actually don’t know how to
653
00:55:30,620 --> 00:55:35,990
answer you how badly we will be bit by it.
But remember that on the other hand
654
00:55:35,990 --> 00:55:41,650
of the balance is how many still say
that they won’t implement TLS
655
00:55:41,650 --> 00:55:45,670
because it’s “slow”. Now, no!
656
00:55:45,670 --> 00:55:51,620
It’s 0-RTT, TLS is fast! Go
out and encrypt everything!
657
00:55:51,620 --> 00:55:57,940
So those are the 2 concerns that
you have to balance together.
658
00:55:57,940 --> 00:56:01,910
Again, my personal opinion
is also worth very little.
659
00:56:01,910 --> 00:56:07,310
This was a decision that was made by
the entire community on the mailing list.
660
00:56:07,310 --> 00:56:12,900
And I can assure you that everyone has
been really conservative with everything,
661
00:56:12,900 --> 00:56:18,630
thinking even… indeed, if the name
would have mislead people. So,
662
00:56:18,630 --> 00:56:23,910
I can’t predict the future. I can only
say that I hope we made the best choice
663
00:56:23,910 --> 00:56:28,520
to make the most part of the
web the most secure we can.
664
00:56:28,520 --> 00:56:32,490
Herald: Next question is from the internet.
665
00:56:32,490 --> 00:56:34,610
Signal Angel, do we have another
question from the internet?
666
00:56:34,610 --> 00:56:37,760
Signal Angel: Yes we do.
667
00:56:37,760 --> 00:56:43,060
What are the major implementation
incompatibilities that were found
668
00:56:43,060 --> 00:56:45,800
now that the actual spec is fairly close?
669
00:56:45,800 --> 00:56:47,910
Herald: Can you repeat that question?
670
00:56:47,910 --> 00:56:53,250
Signal Angel repeats question
671
00:56:53,250 --> 00:56:59,290
Filippo: Okay. As in
during the drafts period?
672
00:56:59,290 --> 00:57:03,450
So, some of the ones that had version
intolerance were mostly, I think,
673
00:57:03,450 --> 00:57:06,750
middle boxes and firewalls.
674
00:57:06,750 --> 00:57:12,690
Nick: There were some very large sites.
I think Paypal was one of them?
675
00:57:12,690 --> 00:57:18,310
Filippo: Although during the process we
had incompatibilities for all kinds of
676
00:57:18,310 --> 00:57:23,540
reasons, including one of
the 2 developers misspelled
677
00:57:23,540 --> 00:57:28,110
the variable number.
laughs
678
00:57:28,110 --> 00:57:32,420
During the drafts sometimes compatibility
broke, but there was a lot of
679
00:57:32,420 --> 00:57:37,970
collaboration between client implementations
and server implementations on our side.
680
00:57:37,970 --> 00:57:44,040
So I’m pretty happy to say that the
actual 1.3 implementations had a lot of
681
00:57:44,040 --> 00:57:50,980
interoperability testing, and all the
issues were pretty quick to be killed.
682
00:57:50,980 --> 00:57:54,050
Herald: Okay, next question
is from microphone number 1.
683
00:57:54,050 --> 00:57:59,300
Question: I have 2 quick questions
concerning session resumption.
684
00:57:59,300 --> 00:58:02,951
If you store some data on a server
from a session, wouldn’t that be
685
00:58:02,951 --> 00:58:08,010
some kind of supercookie?
Is that not privacy-dangerous?
686
00:58:08,010 --> 00:58:13,990
And the second question would be: what
about DNS load balancers or some other
687
00:58:13,990 --> 00:58:21,070
huge amounts of servers where your request
is going to different servers every time?
688
00:58:21,070 --> 00:58:28,150
Filippo: Ok, so, these are details about
deploying session tickets effectively.
689
00:58:28,150 --> 00:58:32,950
TLS 1.3 does think about the privacy
concerns of session tickets; and indeed
690
00:58:32,950 --> 00:58:37,650
it allows the server to send multiple
session tickets. So the server will still
691
00:58:37,650 --> 00:58:42,470
know what client is sending it if it
wants to. But at least anyone looking
692
00:58:42,470 --> 00:58:47,460
at the connection since they are
sent encrypted, not like in 1.2, and
693
00:58:47,460 --> 00:58:53,171
there can be many. Anyone looking at the
connection will not be able to link it
694
00:58:53,171 --> 00:58:57,600
back to the original connection. That’s
the best you can do, because if the server
695
00:58:57,600 --> 00:59:02,560
and the client have to reuse some shared
knowledge the server has to learn about
696
00:59:02,560 --> 00:59:08,240
who it was. But session tickets in 1.3
can’t be tracked by a passive observer,
697
00:59:08,240 --> 00:59:13,010
by a third party, actually. And… when you
do load balancing… there is an interesting
698
00:59:13,010 --> 00:59:18,750
paper about deploying session tickets,
but the gist is that you probably want
699
00:59:18,750 --> 00:59:24,960
to figure out how clients roam between
your servers, and strike a balance between
700
00:59:24,960 --> 00:59:30,340
having to share the session ticket
key so that it’s more effective, and
701
00:59:30,340 --> 00:59:35,500
not sharing the session ticket key which
makes it harder to acquire them all.
702
00:59:35,500 --> 00:59:41,610
You might want to do geographically
located, or in-a-single-rack…
703
00:59:41,610 --> 00:59:44,540
it’s really up to the deployment.
704
00:59:44,540 --> 00:59:47,480
Herald: Okay, final question
goes to microphone 3.
705
00:59:47,480 --> 00:59:51,750
Question: I have a question regarding the
GREASE mechanism that is implemented
706
00:59:51,750 --> 00:59:57,110
on the client side. If I understood
it correctly you are inserting
707
00:59:57,110 --> 01:00:02,350
random version numbers of
not-existing TLS or SSL versions
708
01:00:02,350 --> 01:00:08,640
and that way training
the servers to
709
01:00:08,640 --> 01:00:14,480
conform to the specification. What
is the result of the real-world tests?
710
01:00:14,480 --> 01:00:18,490
How many servers actually
are broken by this?
711
01:00:18,490 --> 01:00:22,780
Filippo: So you would expect none because
after all they are all implementing 1.3
712
01:00:22,780 --> 01:00:28,070
now, so that all the clients they would
see would already be doing GREASE. Instead
713
01:00:28,070 --> 01:00:33,100
just as Google enabled GREASE I think
it broke… I’m not sure so I won’t say
714
01:00:33,100 --> 01:00:38,330
which specific server implementation, but
one of the minor server implementations
715
01:00:38,330 --> 01:00:41,860
was immediately detected
as… the Haskell one!
716
01:00:41,860 --> 01:00:43,890
Nick: Right!
Filippo: I don’t remember the name,
717
01:00:43,890 --> 01:00:47,450
I can’t read Haskell, so I don’t know what
exactly they were doing, but they were
718
01:00:47,450 --> 01:00:49,590
terminating connections because of GREASE.
719
01:00:49,590 --> 01:00:53,480
Nick: And just as a note, GREASE is also
used in cipher negotiation and anything
720
01:00:53,480 --> 01:00:58,800
that is a negotiation in TLS 1.3.
So this actually did break
721
01:00:58,800 --> 01:01:03,020
a subset of servers, but
a small enough subset
722
01:01:03,020 --> 01:01:06,600
that people were happy with it.
723
01:01:06,600 --> 01:01:08,670
Question: Thanks!
Nick: 2% is too high!
724
01:01:08,670 --> 01:01:11,430
Herald: Thank you very much.
Filippo: Thank you!
725
01:01:11,430 --> 01:01:20,010
applause
726
01:01:20,010 --> 01:01:39,080
33C3 postroll music
727
01:01:39,080 --> 01:01:43,981
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!