0:00:00.000,0:00:14.820
33C3 preroll music
0:00:14.820,0:00:20.190
Herald: Basically the upcoming[br]talk is about “Deploying TLS 1.3”
0:00:20.190,0:00:23.509
and is by Filippo Valsorda[br]and Nick Sullivan,
0:00:23.509,0:00:26.989
and they’re both with Cloudflare.
0:00:26.989,0:00:32.110
So please, a warm welcome[br]to Nick and Filippo!
0:00:32.110,0:00:39.490
applause
0:00:39.490,0:00:43.820
Filippo: Hello everyone. Alright,[br]we are here to talk about TLS 1.3.
0:00:43.820,0:00:48.340
TLS 1.3 is of course the latest[br]version of TLS, which stands for
0:00:48.340,0:00:52.960
‘Transport Layer Security’.[br]Now, you might know it best
0:00:52.960,0:00:57.900
as, of course, the green lock in[br]the browser, or by its old name SSL,
0:00:57.900,0:01:02.510
which we are still trying[br]to kill. Now. TLS is
0:01:02.510,0:01:07.890
a transparent security protocol[br]that can tunnel securely
0:01:07.890,0:01:12.460
arbitrary application traffic.[br]It’s used by web browsers, of course,
0:01:12.460,0:01:16.760
it’s used by mail servers to[br]communicate with each other
0:01:16.760,0:01:22.270
to secure SMTP. It’s used by[br]Tor nodes to talk to each other.
0:01:22.270,0:01:26.810
But it evolved over 20 years,
0:01:26.810,0:01:31.320
but at its core it’s about a client[br]and a server that want to communicate
0:01:31.320,0:01:36.119
securely over the network.[br]To communicate securely over the network
0:01:36.119,0:01:41.170
they need to establish some key material,[br]to agree on some key material
0:01:41.170,0:01:47.349
on the two sides to encrypt[br]the rest of the traffic.
0:01:47.349,0:01:51.989
Now how they agree on this key material[br]is [done] in a phase that we call
0:01:51.989,0:01:57.890
the ‘handshake’. The handshake involves[br]some public key cryptography and some data
0:01:57.890,0:02:02.670
being shovelled from the client to the[br]server, from the server to the client.
0:02:02.670,0:02:07.170
Now this is how the handshake[br]looks like in TLS 1.2.
0:02:07.170,0:02:12.790
So the client starts the dances[br]by sending a ‘Client Hello’ over,
0:02:12.790,0:02:18.960
which specifies what supported[br]parameters it can use.
0:02:18.960,0:02:23.430
The server receives that and sends[br]a message of its own, which is
0:02:23.430,0:02:28.200
‘Server Hello’ that says: “Sure![br]Let’s use this cipher suite over here
0:02:28.200,0:02:33.230
that you say you support, and[br]here is my key share to be used
0:02:33.230,0:02:39.270
in this key agreement algorithm.[br]And also here is a certificate
0:02:39.270,0:02:45.300
which is signed by an authority[br]that proves that I am indeed
0:02:45.300,0:02:50.370
Cloudflare.com. And here is a signature[br]from the certificate to prove that
0:02:50.370,0:02:55.450
this key share is actually the one that[br]I want you to use, to establish keys”.
0:02:55.450,0:03:00.940
The client receives that, and it generates[br]its own key share, its own half
0:03:00.940,0:03:06.200
of the Diffie-Hellman key exchange,[br]and sends over the key share,
0:03:06.200,0:03:10.999
and a message to say: “Alright, this[br]is it. This wraps up the handshake”
0:03:10.999,0:03:15.490
which is called the ‘Finished’ message.[br][The] server receives that, makes
0:03:15.490,0:03:20.679
a ‘Finished’ message of its own,[br]and answers with that. So.
0:03:20.679,0:03:25.930
Now we can finally send application[br]data. So to recap, we went:
0:03:25.930,0:03:30.022
Client –> Server, Server –> Client;[br]Client –> Server, Server –> Client.
0:03:30.022,0:03:34.960
We had to do 2 round trips between the[br]client and the server before we could do
0:03:34.960,0:03:40.730
anything. We haven’t sent any[br]byte on the application layer
0:03:40.730,0:03:46.010
until now. Now of course[br]this, on mobile networks
0:03:46.010,0:03:50.539
or in certain parts of the[br]world, can build up
0:03:50.539,0:03:55.320
to hundreds of milliseconds of latency.[br]And this is what needs to happen
0:03:55.320,0:04:00.930
every time a new connection is set up.[br]Every time the client and the server
0:04:00.930,0:04:06.490
have to go twice between them[br]to establish the keys before
0:04:06.490,0:04:12.730
the connection can actually[br]be used. Now, TLS 1.1
0:04:12.730,0:04:17.950
and 1.0 were not that different[br]from 1.2. So you might ask: well, then
0:04:17.950,0:04:23.750
why are we having an entire talk on[br]TLS 1.3, which is probably just this other
0:04:23.750,0:04:31.430
iteration over the same concept? Well,[br]TLS 1.3 is actually a big re-design.
0:04:31.430,0:04:36.740
And in particular, the handshake has been[br]restructured. And the most visible result
0:04:36.740,0:04:43.139
of this is that an entire round[br]trip has been shaved off.
0:04:43.139,0:04:48.929
So, here is how a TLS 1.3[br]handshake looks like.
0:04:48.929,0:04:53.479
How does 1.3 remove a round trip?[br]How can it do that? Well, it does that
0:04:53.479,0:04:59.799
by predicting what key agreement algorithm
0:04:59.799,0:05:04.740
the server will decide to use, and[br]sending pre-emptively a key share
0:05:04.740,0:05:10.029
for that algorithm to the server.[br]So with the first flight we had
0:05:10.029,0:05:15.529
the ‘Client Hello’, the supported[br]parameters, and a key share
0:05:15.529,0:05:21.549
for the one that the client thinks the[br]server will like. The server receives that
0:05:21.549,0:05:27.239
and if everything goes well, it will[br]go like “Oh! Sure! I like this key share.
0:05:27.239,0:05:32.789
Here is my own key share to run[br]the same algorithm, and here is
0:05:32.789,0:05:37.719
the other parameters we should use.”[br]It immediately mixes the two key shares
0:05:37.719,0:05:42.319
to get a shared key, because now[br]it has both key shares – the client’s
0:05:42.319,0:05:47.089
and the server’s – and sends again[br]the certificate and a signature
0:05:47.089,0:05:51.339
from the certificate, and then[br]immediately sends a ‘Finished’ message
0:05:51.339,0:05:56.339
because it doesn’t need anything else[br]from the client. The client receives that,
0:05:56.339,0:06:02.020
takes the key share, mixes the shared key[br]and sends its own ‘Finished’ message,
0:06:02.020,0:06:07.009
and is ready to send whatever application[br]layer data it was waiting to send.
0:06:07.009,0:06:12.650
For example your HTTP[br]request. Now we went:
0:06:12.650,0:06:15.919
Client –> Server, Server –> Client.
0:06:15.919,0:06:21.330
And we are ready to send data at the[br]application layer. So you are trying
0:06:21.330,0:06:27.239
to setup a HTTPS connection[br]and your browser
0:06:27.239,0:06:32.769
doesn’t need to wait 4x[br]the latency, or 4x the ping.
0:06:32.769,0:06:38.929
It only has to wait 2x. And of course[br]this saves hundreds of milliseconds
0:06:38.929,0:06:46.199
of latency when setting up fresh[br]connections. Now, this is the happy path.
0:06:46.199,0:06:52.299
So this is what happens when the[br]prediction is correct and the server likes
0:06:52.299,0:06:58.449
the client key share. If the server[br]doesn’t support the key share
0:06:58.449,0:07:05.169
that the client sent it will send a polite[br]request to use a different algorithm
0:07:05.169,0:07:10.530
that the client said it can support. We[br]call that message ‘Hello Retry Request’.
0:07:10.530,0:07:16.469
It has a cookie, so that can be stateless,[br]but essentially it makes a fall-back
0:07:16.469,0:07:21.970
to what is effectively a TLS-1.2-like[br]handshake. And it’s not that hard
0:07:21.970,0:07:26.939
to implement because the client follows up[br]with a new ‘Client Hello’ which looks
0:07:26.939,0:07:34.489
essentially exactly like a fresh one. Now.
0:07:34.489,0:07:42.179
Here I’ve been lying to you.[br]TLS 1.2 is not always 2 round trips.
0:07:42.179,0:07:47.779
Most of the connections we see from the[br]Cloudflare edge e.g. are ‘resumptions’.
0:07:47.779,0:07:53.299
That means that the client has connected[br]to that website before in the past.
0:07:53.299,0:07:59.079
And we can use that, we can exploit[br]that to make the handshake faster.
0:07:59.079,0:08:06.290
That means that the client can remember[br]something about the key material
0:08:06.290,0:08:10.959
to make the next connection[br]a round trip even in TLS 1.2.
0:08:10.959,0:08:16.019
So here is how it looks like. Here[br]you have your normal TLS 1.2 full
0:08:16.019,0:08:22.479
2-round trip connection. And over[br]here it sends a new session ticket.
0:08:22.479,0:08:30.029
A session ticket is nothing else than a[br]encrypted wrapped blob of key material
0:08:30.029,0:08:35.100
that the client will hold on to. The[br]session ticket is encrypted and signed
0:08:35.100,0:08:40.039
with a key that only the server knows.[br]So it’s completely opaque to the client.
0:08:40.039,0:08:45.040
But the client will keep it together[br]with the key material of the connection,
0:08:45.040,0:08:49.340
so that the next time it makes[br]a connection to that same website
0:08:49.340,0:08:54.439
it will send a ‘Client Hello’,[br]and a session ticket.
0:08:54.439,0:08:59.180
If the server recognises the session[br]ticket it will decrypt it, find inside
0:08:59.180,0:09:04.090
the key material. And now, after only one[br]round trip, the server will have some
0:09:04.090,0:09:09.820
shared key material with the client because[br]the client held on to the key material
0:09:09.820,0:09:15.460
from last time and the server just[br]decrypted it from the session ticket.
0:09:15.460,0:09:20.890
OK? So now the server has some shared[br]keys to use already, and it sends
0:09:20.890,0:09:26.150
a ‘Finished’ message, and the client sends[br]its own ‘Finished’ message and the request.
0:09:26.150,0:09:31.550
So this is TLS 1.2. This is what[br]is already happening every day
0:09:31.550,0:09:37.380
with most modern TLS connections. Now.
0:09:37.380,0:09:43.530
TLS 1.3 resumption is not that different.[br]It still has the concept of a session ticket.
0:09:43.530,0:09:48.300
We changed the name of what’s inside[br]the session ticket to a ‘PSK’ but that
0:09:48.300,0:09:53.220
just means ‘Pre-shared Key’ because[br]that’s what it is: it’s some key material
0:09:53.220,0:09:58.480
that was agreed upon in advance.[br]And it works the same way:
0:09:58.480,0:10:02.830
the server receives the session[br]ticket, decrypts it and jumps to the
0:10:02.830,0:10:07.450
‘Finished’ message. Now,
0:10:07.450,0:10:13.070
a problem with resumption[br]is that if an attacker
0:10:13.070,0:10:17.130
controls the session ticket key[br]– the key that the server uses
0:10:17.130,0:10:21.540
to encrypt the session ticket that[br]has inside the key material –
0:10:21.540,0:10:27.050
an attacker can passively or in the future[br]even, with a recording of the connection,
0:10:27.050,0:10:33.460
decrypt the session ticket from the[br]‘Client Hello’, find the PSK inside it
0:10:33.460,0:10:38.320
and use it to decrypt the rest of[br]the connection. This is not good.
0:10:38.320,0:10:42.519
This means that someone can do[br]passive decryption by just having
0:10:42.519,0:10:47.819
the session ticket key. How this is[br]addressed usually is that we say
0:10:47.819,0:10:52.540
that session ticket keys are short-[br]lived. But still it would be nice if
0:10:52.540,0:10:56.270
we didn’t have to rely on that. And there[br]are actually nice papers that tell us
0:10:56.270,0:11:01.310
that implementations don’t[br]always do this right. So,
0:11:01.310,0:11:07.050
instead what TLS 1.3 allows[br]us to do is use Diffie-Hellman
0:11:07.050,0:11:11.760
with resumption. In 1.2 there[br]was no way to protect
0:11:11.760,0:11:16.720
against session ticket key[br]compromise. In 1.3 what you can do
0:11:16.720,0:11:21.409
is send a key share as part[br]of the ‘Client Hello’ anyway,
0:11:21.409,0:11:25.499
and the server will send a key share[br]together with the ‘Server Hello’,
0:11:25.499,0:11:31.710
and they will run Diffie-Hellman.[br]Diffie-Hellman is what was used to
0:11:31.710,0:11:36.009
introduce forward secrecy against[br]the compromise of, for example,
0:11:36.009,0:11:41.339
the certificate private key in 1.2, and[br]it’s used here to provide forward secrecy
0:11:41.339,0:11:46.290
for resumed connections.[br]Now, you will say:
0:11:46.290,0:11:51.240
“Now this looks essentially[br]like a normal 1.3 handshake,
0:11:51.240,0:11:55.770
why having the PSK at all?” Well,[br]there is something missing from this one,
0:11:55.770,0:11:59.510
there is no certificate. Because[br]there is no need to re-authenticate
0:11:59.510,0:12:04.620
with a certificate because the client and[br]the server spoke in the past, and so
0:12:04.620,0:12:09.099
the client knows that it already checked[br]the certificate of the server and
0:12:09.099,0:12:12.819
if the server can decrypt the session[br]ticket it means that it’s actually
0:12:12.819,0:12:17.879
who it says it is. So, the two[br]key shares get mixed together.
0:12:17.879,0:12:22.860
Then mixed with the PSK to make[br]a key that encrypts the rest
0:12:22.860,0:12:29.580
of the connection. Now.[br]There is one other feature
0:12:29.580,0:12:34.701
that is introduced by TLS 1.3[br]resumption. And that is the fact
0:12:34.701,0:12:40.830
that it allows us to make 0-round[br]trip handshakes. Again,
0:12:40.830,0:12:47.280
all handshakes in 1.3[br]are mostly 1-round trip.
0:12:47.280,0:12:52.140
TLS 1.2 resumptions can be[br]at a minimum 1-round trip.
0:12:52.140,0:12:58.331
TLS 1.3 resumptions can be 0-round[br]trip. How does a 0-round trip
0:12:58.331,0:13:04.210
handshake work? Well, if you think about[br]it, when you start, you have a PSK,
0:13:04.210,0:13:10.119
a Pre-Shared Key. The client[br]can just use that to encrypt
0:13:10.119,0:13:15.680
this early data that it wants to[br]send to the server. So the client
0:13:15.680,0:13:20.439
opens a connection, to a server that it[br]has already connected to in the past,
0:13:20.439,0:13:25.349
and sends ‘Client Hello’, session ticket,
0:13:25.349,0:13:29.920
key share for Diffie-Hellman and[br]then early data. Early data is
0:13:29.920,0:13:34.410
this blob of application data[br]– it can be e.g. a HTTP request –
0:13:34.410,0:13:39.409
encrypted with the PSK.[br]The server receives this,
0:13:39.409,0:13:45.369
decrypts the session ticket, finds[br]the PSK, uses the PSK to decrypt the
0:13:45.369,0:13:50.770
early data and then proceeds as normal:[br]mixes the 2 key shares, mixes the PSK in,
0:13:50.770,0:13:55.270
makes a new key for the rest of the[br]connection and continues the connection.
0:13:55.270,0:14:00.289
So what happened here? We were able to[br]send application data immediately upon
0:14:00.289,0:14:05.339
opening the connection. This means that[br]we completely removed the performance
0:14:05.339,0:14:11.320
overhead of TLS. Now.
0:14:11.320,0:14:16.460
0-RTT handshakes, though, have[br]2 caveats that are theoretically
0:14:16.460,0:14:22.540
impossible to remove. One is that[br]that nice thing that we introduced
0:14:22.540,0:14:27.829
with the PSK ECDHE mode, the one where[br]we do Diffie-Hellman for resumption
0:14:27.829,0:14:33.040
in 1.3, does not help with 0-RTT data.
0:14:33.040,0:14:38.620
We do Diffie-Hellman when we[br]reach the green box in the slide.
0:14:38.620,0:14:44.000
Of course the early data is only encrypted[br]with the PSK. So let’s think about
0:14:44.000,0:14:49.150
the attacker again. The attacker somehow[br]stole our session ticket encryption keys.
0:14:49.150,0:14:54.969
It can look at the ‘Client Hello’, decrypt[br]the session ticket, get the PSK out,
0:14:54.969,0:15:00.029
use the PSK to decrypt the early data.
0:15:00.029,0:15:05.350
And it can do this even from a recording[br]if it gets the session ticket later on.
0:15:05.350,0:15:11.519
So the early data is not forward secret[br]with respect to the session ticket keys.
0:15:11.519,0:15:16.679
Then of course it becomes useless[br]if we are doing Diffie-Hellman to get
0:15:16.679,0:15:23.020
the server answer. That’s only useful[br]for the first flight sent from the client.
0:15:23.020,0:15:28.340
So to recap, a lot of things[br]going on here: TLS 1.2
0:15:28.340,0:15:33.379
introduced forward secrecy[br]against the compromise of the
0:15:33.379,0:15:39.119
certificate private keys, a long[br]time ago, by using ECDHE modes.
0:15:39.119,0:15:45.030
So 1.2 connections can be[br]always forward secret against
0:15:45.030,0:15:50.300
certificate compromise.[br]TLS 1.3 has that always on as well.
0:15:50.300,0:15:55.090
There is no mode that is not forward[br]secret against compromise of the
0:15:55.090,0:16:01.279
certificate. But when we think about what[br]might happen to the session ticket key:
0:16:01.279,0:16:06.000
TLS 1.2 never provides forward secrecy.
0:16:06.000,0:16:11.149
In TLS 1.2 compromising the session[br]ticket key always means being able
0:16:11.149,0:16:15.819
to passively and in the future[br]decrypt resumed connections.
0:16:15.819,0:16:22.689
In 1.3 instead, if we use PSK[br]ECDHE only the early data
0:16:22.689,0:16:28.270
can be decrypted by using[br]the session ticket key alone.
0:16:28.270,0:16:33.199
Now, I said that there were 2 caveats.
0:16:33.199,0:16:39.329
The second caveat is that[br]0-RTT data can be replayed.
0:16:39.329,0:16:45.449
The scenario is this: you have[br]some data in the early data
0:16:45.449,0:16:51.709
that is somehow authenticated. It might be[br]a HTTP request with some cookies on it.
0:16:51.709,0:16:58.070
And that HTTP request is somehow[br]executing a transaction,
0:16:58.070,0:17:03.150
okay? Moving some money, instructing[br]the server to do something. An attacker
0:17:03.150,0:17:07.580
wants to make that happen multiple[br]times. It can’t decrypt it, of course
0:17:07.580,0:17:13.149
– it’s protected with TLS. So it[br]can’t read the cookie, and it can’t
0:17:13.149,0:17:17.689
modify it because, of course, it’s[br]protected with TLS. But it can record
0:17:17.689,0:17:23.069
the encrypted message[br]and it can then replay it
0:17:23.069,0:17:27.900
against the server. Now if you have[br]a single server this is easy to fix.
0:17:27.900,0:17:32.520
You just take a note of the messages you[br]have seen before and you just say like
0:17:32.520,0:17:37.500
“No, this looks exactly like something I[br]got before”. But if, for example like
0:17:37.500,0:17:42.270
Cloudflare you are running multiple data[br]centres around the world, you cannot keep
0:17:42.270,0:17:47.650
consistent state all the time, in real[br]time across all machines. So there would
0:17:47.650,0:17:52.370
be different machines that if they[br]receive this message will go like
0:17:52.370,0:17:57.530
“Sure I have the session ticket key,[br]I decrypt the PSK, I use the PSK,
0:17:57.530,0:18:02.080
I decrypt the early data, I find[br]inside something, I execute what
0:18:02.080,0:18:07.510
it tells me to do.” Now, of[br]course, this is not desirable.
0:18:07.510,0:18:13.010
One countermeasure that TLS offers[br]is that the client sends a value
0:18:13.010,0:18:18.689
in that bundle which is how long[br]ago in milliseconds I obtained
0:18:18.689,0:18:23.790
the session ticket. The server[br]looks at that value and
0:18:23.790,0:18:29.080
if it does not match its own view of this[br]information it will reject the message.
0:18:29.080,0:18:34.020
That means that if the attacker records[br]the message and then 10 seconds later
0:18:34.020,0:18:40.000
tries to replay it the times won’t[br]match and the server can drop it.
0:18:40.000,0:18:44.510
But this is not a full solution because[br]if the attacker is fast enough
0:18:44.510,0:18:50.369
it can still replay messages.[br]So, everything the server can do
0:18:50.369,0:18:55.970
is either accept the[br]0-RTT data, or reject it.
0:18:55.970,0:19:00.570
It can’t just take some part of it or[br]take a peek and then decide because
0:19:00.570,0:19:05.540
it’s the ‘Server Hello’ message that[br]says whether it’s accepted or rejected.
0:19:05.540,0:19:09.759
And the client will keep sending early[br]data until it gets the ‘Server Hello’.
0:19:09.759,0:19:15.960
There’s a race here. So the server has to[br]go blind and decide “Am I taking 0-RTT data
0:19:15.960,0:19:20.990
or am I just rejecting it all?” If it’s[br]taking it, and then it finds out that it’s
0:19:20.990,0:19:26.750
something that it can’t process because[br]“Oh god, there is a HTTP POST in here
0:19:26.750,0:19:32.470
that says to move some money, I can’t[br]do this unless I know it’s not replayed.”
0:19:32.470,0:19:37.060
So the server has to get some[br]confirmation. The good news is that
0:19:37.060,0:19:40.600
if the server waits for the ‘Finished’[br]message… The server sends
0:19:40.600,0:19:45.280
the ‘Server Hello’, the ‘Finished’[br]and waits for the client’s one.
0:19:45.280,0:19:51.050
When the client’s one gets there it means[br]that also the early data was not replayed,
0:19:51.050,0:19:54.950
because that ‘Finished’ message[br]ties together the entire handshake
0:19:54.950,0:19:59.769
together with some random value that[br]the server sent. So it’s impossible
0:19:59.769,0:20:04.380
that it was replayed. So, this is[br]what a server can do: it can accept
0:20:04.380,0:20:08.780
the early data and if it’s something[br]that is not idempotent, something
0:20:08.780,0:20:14.610
that is dangerous, if it’s replayed it[br]can just wait for the confirmation.
0:20:14.610,0:20:18.850
But that means it has to buffer it, and[br]there’s a risk for an attack here, where
0:20:18.850,0:20:25.580
an attacker just sends a HTTP POST, with[br]a giant body just to fill your memory.
0:20:25.580,0:20:31.840
So what we realised is that we could help[br]with this if we wrote on the session tickets
0:20:31.840,0:20:37.240
what’s the maximum amount of[br]early data that the client can send.
0:20:37.240,0:20:41.500
If we see someone sending more than[br]that, then it’s an attacker and we
0:20:41.500,0:20:47.499
close the connection, drop the[br]buffer, free up the memory.
0:20:47.499,0:20:52.969
But. Anyway. However[br]countermeasures we deploy,
0:20:52.969,0:20:58.780
unless we can keep global state across the[br]servers, we have to inform the application
0:20:58.780,0:21:03.429
that “this data might be replayed”.[br]The spec knows this.
0:21:03.429,0:21:08.150
So the TLS 1.3 spec EXPLICITLY says
0:21:08.150,0:21:14.420
protocols must NOT use[br]0-RTT without a profile
0:21:14.420,0:21:19.159
that defines its use. Which means[br]“without knowing what they are doing”.
0:21:19.159,0:21:24.419
This means that TLS stack[br]API’s have to do 1 round trip
0:21:24.419,0:21:30.360
by default, which is not affected by[br]replays, and then allow the server
0:21:30.360,0:21:35.571
to call some API’s to either reject[br]or wait for the confirmation,
0:21:35.571,0:21:41.470
and to let the client decide what goes[br]into this dangerous re-playable
0:21:41.470,0:21:46.040
piece of data. So this will change
0:21:46.040,0:21:49.840
based on the protocols but what about[br]our favourite protocol? What about
0:21:49.840,0:21:55.329
HTTP? Now HTTP should[br]be easy, the HTTP spec,
0:21:55.329,0:22:00.759
you go read it and it says “Well,[br]GET requests are idempotent,
0:22:00.759,0:22:06.149
they must not change anything on the[br]server”. Solved! We will just allow
0:22:06.149,0:22:10.670
GET requests in early data because even[br]if they are replayed nothing happened!
0:22:10.670,0:22:16.640
Yay! Nope. sighs You will definitely[br]find some server on the internet
0:22:16.640,0:22:23.020
that has something like[br]“send-money.php?to=filippo&amount=this”
0:22:23.020,0:22:28.870
and it’s a GET request. And if an attacker[br]records this, which is early data,
0:22:28.870,0:22:33.510
and then replays this against a different[br]server in the pool, that will get executed
0:22:33.510,0:22:38.780
twice. And we can’t have that.
0:22:38.780,0:22:43.300
Now, so what can we do here?
0:22:43.300,0:22:46.890
We make trade-offs!
0:22:46.890,0:22:51.779
If you know your application, you can[br]make very specific trade-offs. E.g.
0:22:51.779,0:22:57.020
Google has been running QUIC[br]with 0-RTT for the longest time,
0:22:57.020,0:23:02.200
for 3 years I think? And that means that[br]they know very well their application.
0:23:02.200,0:23:07.419
And they know that they don’t have[br]any “send-money.php” endpoints.
0:23:07.419,0:23:12.710
But if you are like Cloudflare that[br]fronts a wide number of applications
0:23:12.710,0:23:17.720
you can’t make such wide sweeping[br]assumptions, and you have instead
0:23:17.720,0:23:22.570
to hope for some middle ground. For[br]example, something we might decide to do
0:23:22.570,0:23:28.730
is to only allow GETs[br]to the root. So “GET /”
0:23:28.730,0:23:33.200
which might be the most benefit because[br]maybe most connections start like that,
0:23:33.200,0:23:38.710
and the least likely to cause trouble.
0:23:38.710,0:23:43.140
We are still working on how exactly to[br]bring this to applications. So if you know
0:23:43.140,0:23:48.199
of an application that would get hurt[br]by something as simple as that
0:23:48.199,0:23:53.840
do email us, but actually,[br]if you have an application
0:23:53.840,0:23:59.160
that is that vulnerable I have[br]bad news. Thai Duong et. al.
0:23:59.160,0:24:04.150
demonstrated that browsers will[br]today, without TLS 1.3 or anything,
0:24:04.150,0:24:09.740
replay HTTP requests[br]if network errors happen.
0:24:09.740,0:24:15.670
And they will replay them silently.[br]So it might not be actually worse
0:24:15.670,0:24:21.990
than the current state. Okay.[br]I can actually see everyone
0:24:21.990,0:24:27.959
getting uneasy in their seats, thinking[br]“There the cryptographers are at it again!
0:24:27.959,0:24:32.740
They are making the security protocol that[br]we need more complex than it has to be
0:24:32.740,0:24:38.889
to get their job security for[br]the next 15 years!” Right?
0:24:38.889,0:24:44.479
No. No. I can actually assure you that
0:24:44.479,0:24:49.709
one of the big changes, in my opinion[br]even bigger than the round trips in 1.3,
0:24:49.709,0:24:54.770
is that everything is being weighted[br]for the benefit against the complexity
0:24:54.770,0:24:59.180
that it introduces. And[br]while 0-RTT made the cut
0:24:59.180,0:25:02.630
most other things definitely didn’t.
0:25:02.630,0:25:07.890
Nick: Right. Thanks Filippo.
0:25:07.890,0:25:13.640
In TLS 1.3 as an iteration of[br]TLS we also went back, or,
0:25:13.640,0:25:18.120
“we” being the people who are[br]looking at TLS, went back and
0:25:18.120,0:25:22.770
revisited the existing TLS 1.2 features[br]that sort of seemed reasonable at the time
0:25:22.770,0:25:27.439
and decided whether or not the complexity[br]and the danger added by these features,
0:25:27.439,0:25:32.349
or these protocols, or these[br]primitives involved in TLS were
0:25:32.349,0:25:37.739
reasonable to keep. And the big one which[br]happened early on in the process is
0:25:37.739,0:25:43.790
‘Static RSA’ mode. So this is the way that[br]TLS has been working back since SSL.
0:25:43.790,0:25:48.179
Rather than using Diffie-Hellman to[br]establish a shared key… How this works is,
0:25:48.179,0:25:52.320
the client will make its own shared[br]key, and encrypt it with the server’s
0:25:52.320,0:25:56.570
certificate public key which is gonna[br]be an RSA key, and then just send it
0:25:56.570,0:26:00.770
in plain text over the wire to the server.[br]And then the server would use its
0:26:00.770,0:26:04.650
private key to decrypt that, and then[br]establish a shared key. So the client
0:26:04.650,0:26:09.710
creates all the key material in this case.[br]And one thing that is sort of obvious
0:26:09.710,0:26:13.650
from this is that if the private key[br]for the certificate is comprised,
0:26:13.650,0:26:18.149
even after the fact, even years later,[br]someone with the transcript of what happened
0:26:18.149,0:26:23.480
can go back and decrypt this key material,[br]and then see the entire conversation.
0:26:23.480,0:26:28.419
So this was removed very early in the[br]process, somewhere around 2 years ago
0:26:28.419,0:26:33.919
in TLS 1.3. So, much to our surprise,[br]and the surprise of everyone
0:26:33.919,0:26:39.680
reading the TLS mailing[br]list, just very recently,
0:26:39.680,0:26:44.610
near the end of the standardisation[br]process where TLS 1.3 was almost final
0:26:44.610,0:26:50.800
this e-mail landed on the list. And this[br]is from Andrew Kennedy who works at BITS
0:26:50.800,0:26:56.550
which basically means he works[br]at banks. So this is what he said:
0:26:56.550,0:27:01.670
“Deprecation of the RSA key exchange[br]in TLS 1.3 will cause significant problems
0:27:01.670,0:27:06.760
for financial institutions, almost all of[br]whom are running TLS internally and have
0:27:06.760,0:27:12.510
significant, security-critical investments[br]in out-of-band TLS decryption”.
0:27:12.510,0:27:17.810
“Out-of-band TLS decryption”… mmh…[br]laughs - applause
0:27:17.810,0:27:23.490
That certainly sounds critical…[br]critical for someone, right?
0:27:23.490,0:27:26.140
laughs - applause[br]So…
0:27:26.140,0:27:32.200
laughs[br]applause
0:27:32.200,0:27:37.039
So one of the bright spots was[br]Kenny Paterson’s response to this,
0:27:37.039,0:27:41.680
in which he said: “My view[br]concerning your request: no.
0:27:41.680,0:27:44.920
Rationale: We’re trying to build a MORE[br]secure internet.” The emphasis on ‘more’
0:27:44.920,0:27:47.350
is mine but I’m sure he meant it, yeah.
0:27:47.350,0:27:54.100
applause
0:27:54.100,0:27:58.840
So after this the banking folks came[br]to the IETF and presented this slide
0:27:58.840,0:28:04.460
to describe how hard it was to actually[br]debug their system. This is a very simple…
0:28:04.460,0:28:09.270
I guess, with respect to banking. Those[br]are the different switches, routers,
0:28:09.270,0:28:14.480
middle ware, web applications; and[br]everything talks TLS one to the other.
0:28:14.480,0:28:19.730
And after this discussion we decided[br]we came to a compromise.
0:28:19.730,0:28:24.160
But instead of actually compromising[br]the protocol Matthew Green
0:28:24.160,0:28:28.900
taught them how to use Diffie-Hellman[br]incorrectly. They ended up actually
0:28:28.900,0:28:33.110
being able to do what they wanted[br]to do, without us – or anybody
0:28:33.110,0:28:36.780
in the academic community, or in the[br]TLS community – adding back this
0:28:36.780,0:28:41.720
insecure piece of TLS.
0:28:41.720,0:28:45.580
So if you want to read this it shows[br]how to do it. But in any case
0:28:45.580,0:28:49.970
– we didn’t add it back.[br]Don’t do this, basically! laughs
0:28:49.970,0:28:54.300
applause
0:28:54.300,0:29:00.100
So we killed static RSA, and[br]what else did we kill? Well,
0:29:00.100,0:29:03.769
looking back on the trade-offs there is[br]a number of primitives that are in use
0:29:03.769,0:29:08.519
in TLS 1.2 and earlier that just[br]haven’t stood the test of time.
0:29:08.519,0:29:12.130
So, RC4 stream cipher. Gone![br]applause
0:29:12.130,0:29:14.790
3DES (Triple DES) block cipher. Gone![br]applause
0:29:14.790,0:29:21.529
MD5, SHA1… all gone. Yo![br]ongoing applause
0:29:21.529,0:29:26.480
There is even constructions that took…[br]basic block cipher constructions
0:29:26.480,0:29:31.640
that are gone: AES-CBC.[br]Gone. RSA-PKCS1-1.5,
0:29:31.640,0:29:36.810
this has been known to have been[br]problematic since 1998, also gone!
0:29:36.810,0:29:41.770
They have also removed several features[br]like Compression and Renegotiation which
0:29:41.770,0:29:47.130
was replaced with a very lightweight[br]‘key update’ mechanism. So in TLS 1.3
0:29:47.130,0:29:52.490
none of these met the balance of[br]benefit vs. complexity. And a lot of these
0:29:52.490,0:29:58.030
vulnerabilities, you might recognize, are[br]just impossible in TLS 1.3. So that’s good.
0:29:58.030,0:30:04.010
applause
0:30:04.010,0:30:09.149
So the philosophy for TLS 1.3 in a lot of[br]places is simplify and make it more robust
0:30:09.149,0:30:14.549
as much as possible. There are a number[br]of little cases in which we did that.
0:30:14.549,0:30:18.680
Some of the authors of this paper may be[br]in the audience right now. But there is
0:30:18.680,0:30:24.030
a way in which block ciphers where[br]used for the actual record layer
0:30:24.030,0:30:27.640
that was not as robust as it could be.[br]It has been replaced with a much simpler
0:30:27.640,0:30:32.340
mechanism. TLS 1.2 had this
0:30:32.340,0:30:37.520
really kind of funny ‘Catch 22’ in it[br]where the cipher negotiation
0:30:37.520,0:30:41.810
is protected by a ‘Finished’ message which[br]is a message-authentication code, but
0:30:41.810,0:30:47.020
the algorithm for that code was determined[br]in the cipher negotiation, so,
0:30:47.020,0:30:53.090
it had this kind of loop-back effect. And[br]attacks like FREAK, LogJam and CurveSwap
0:30:53.090,0:30:59.300
(from last year) managed to exploit these[br]to actually downgrade connections.
0:30:59.300,0:31:02.669
And this was something that was happening[br]in the wild. And the reason for this is
0:31:02.669,0:31:06.980
that these cipher suites in this handshake[br]are not actually digitally signed
0:31:06.980,0:31:11.649
by the private key. And in TLS 1.3[br]this was changed. Everything
0:31:11.649,0:31:16.129
from the signature up is digitally[br]signed. So this is great!
0:31:16.129,0:31:21.290
What else did we change? Well,[br]what else did TLS 1.3 change
0:31:21.290,0:31:27.860
vs. TLS 1.2? And that is: fewer, better[br]choices. And in cryptography
0:31:27.860,0:31:33.410
better choices always means fewer choices.[br]So there is now a shortlist of curves and
0:31:33.410,0:31:36.920
finite field groups that you can use. And[br]no arbitrary Diffie-Hellman groups made up
0:31:36.920,0:31:41.949
by the server, no arbitrary curves[br]that can be used. And this sort of
0:31:41.949,0:31:47.940
shortening of the list of parameters[br]really enables 1-RTT to work
0:31:47.940,0:31:51.960
a lot of the time. So as Filippo[br]mentioned, the client has to guess
0:31:51.960,0:31:56.540
which key establishment[br]methods the server supports,
0:31:56.540,0:32:01.199
and send that key share. If there is[br]a short list of only-secure options
0:32:01.199,0:32:05.599
this happens a larger percentage of[br]the time. So when you’re configuring
0:32:05.599,0:32:10.760
your TLS server it no longer looks[br]like a complicated takeout menu,
0:32:10.760,0:32:15.690
it’s more like a wedding [menu]. Take one[br]of each, and it’s a lot more delicious
0:32:15.690,0:32:21.970
anyways. And you can look on[br]Wireshark, it’s also very simple.
0:32:21.970,0:32:27.800
The cipher suites use extensions,[br]the curves, and you can go from there.
0:32:27.800,0:32:33.301
Filippo: Now, TLS 1.3 also fixed[br]what I think was one of the biggest
0:32:33.301,0:32:37.441
actual design mistakes of[br]TLS 1.2. We talked about
0:32:37.441,0:32:43.410
how forward secrecy works[br]with resumption in 1.2 and 1.3.
0:32:43.410,0:32:49.199
But TLS 1.2 is even more[br]problematic. TLS 1.2 wraps
0:32:49.199,0:32:55.679
inside the session tickets the actual[br]master secret of the old connection.
0:32:55.679,0:33:02.509
So it takes the actual keys that encrypt[br]the traffic of the original connection,
0:33:02.509,0:33:07.860
encrypts them with the session ticket key,[br]and sends that to the client to be sent
0:33:07.860,0:33:13.619
back the next time. We talked about[br]how there’s a risk that an attacker will
0:33:13.619,0:33:18.139
obtain session ticket keys, and decrypt[br]the session tickets, and break
0:33:18.139,0:33:23.859
the forward secrecy and decrypt[br]the resumed connections. Well,
0:33:23.859,0:33:29.780
in TLS 1.2 it’s even worse. If they[br]decrypt the session tickets they could
0:33:29.780,0:33:35.950
go back and backward decrypt the original
0:33:35.950,0:33:42.090
non-resumed connection. And[br]this is completely unnecessary.
0:33:42.090,0:33:46.770
We have hash functions, we have one-way[br]functions where you put an input in
0:33:46.770,0:33:52.990
and you get something that you can’t[br]go back from. So that’s what 1.3 does.
0:33:52.990,0:33:58.579
1.3 derives new keys, fresh[br]keys for the next connection
0:33:58.579,0:34:04.090
and wraps them inside the session ticket[br]to become the PSK. So even if you
0:34:04.090,0:34:09.439
decrypt a 1.3 session ticket[br]you can then attack
0:34:09.439,0:34:13.619
the subsequent connection, and we’ve[br]seen that you might be able to decrypt
0:34:13.619,0:34:18.949
only the early data, or all the connection[br]depending on what mode it uses. But
0:34:18.949,0:34:25.959
you definitely can’t decrypt the[br]original non-resumed connection.
0:34:25.959,0:34:31.729
So, this would be bad enough, but 1.2[br]makes another decision that entirely
0:34:31.729,0:34:36.760
puzzled me. The whole ‘using the master[br]secret’ might be just because session
0:34:36.760,0:34:41.779
tickets were an extension in[br]1.2, which they are not in 1.3.
0:34:41.779,0:34:47.990
But, 1.2 sends the new session[br]ticket message at the beginning
0:34:47.990,0:34:53.490
of the original handshake,[br]unencrypted! I mean
0:34:53.490,0:34:58.670
encrypted with the session ticket keys[br]but not with the current session keys.
0:34:58.670,0:35:04.040
So, any server that just supports
0:35:04.040,0:35:10.130
session tickets will have at the[br]beginning of all connections,
0:35:10.130,0:35:14.670
even if resumption never happens, they[br]will have a session ticket which is
0:35:14.670,0:35:18.820
nothing else than the ephemeral[br]keys of that connection
0:35:18.820,0:35:23.400
wrapped with the session[br]ticket keys. Now, if you are
0:35:23.400,0:35:28.620
a global passive adversary[br]that somehow wants to do
0:35:28.620,0:35:33.060
passive dragnet surveillance and[br]you wanted to passively decrypt
0:35:33.060,0:35:38.720
all the connections, and somehow you[br]were able to obtain session ticket keys,
0:35:38.720,0:35:44.350
what you would find at the beginning[br]of every TLS 1.2 connection is
0:35:44.350,0:35:49.830
the session keys encrypted with[br]the session ticket keys. Now,
0:35:49.830,0:35:55.580
1.3 solves this, and in 1.3 this kind[br]of attacks are completely impossible.
0:35:55.580,0:35:59.420
The only thing that you can passively[br]decrypt, or decrypt after the fact,
0:35:59.420,0:36:04.230
is the early data, and definitely not non-[br]resumed connections, and definitely not
0:36:04.230,0:36:10.920
anything that comes after 0-RTT.
0:36:10.920,0:36:12.840
Nick: So it’s safer, basically.[br]laughs
0:36:12.840,0:36:15.710
Filippo: Hope so![br]Nick: …hopefully.
0:36:15.710,0:36:20.670
And how do we know that it’s safer? Well,[br]these security parameters, and these
0:36:20.670,0:36:25.840
security requirements of TLS have been[br]formalized and, as opposed to earlier
0:36:25.840,0:36:30.310
versions of TLS the folks in the academic[br]community who do formal verification were
0:36:30.310,0:36:34.170
involved earlier. So there have been[br]several papers analyzing the state machine
0:36:34.170,0:36:40.120
and analyzing the different modes of[br]TLS 1.3, and these have aided a lot
0:36:40.120,0:36:45.360
in the development[br]of the protocol. So,
0:36:45.360,0:36:50.570
who actually develops TLS 1.3? Well, it’s
0:36:50.570,0:36:54.730
an organization called the IETF which is[br]the Internet Engineering Taskforce. It’s
0:36:54.730,0:36:59.760
a group of volunteers that meet 3 times[br]a year and have mailing lists, and they
0:36:59.760,0:37:03.461
debate these protocols endlessly. They[br]define the protocols that are used
0:37:03.461,0:37:07.910
on the internet. And originally, the first[br]thing that I ever saw about this – this is
0:37:07.910,0:37:13.250
a tweet of mine from September[br]2013 – was a wish list for TLS 1.3.
0:37:13.250,0:37:19.920
And since then they came out[br]with a first draft at the IETF…
0:37:19.920,0:37:24.630
Documents that define protocols[br]are known as RFCs, and
0:37:24.630,0:37:29.200
the lead-up to something becoming an RFC[br]is an ‘Internet Draft’. So you start with
0:37:29.200,0:37:34.330
the Internet Draft 0, and then you iterate[br]on this draft until finally it gets
0:37:34.330,0:37:39.980
accepted or rejected as an RFC. So[br]the first one was almost 3 years ago
0:37:39.980,0:37:46.080
back in April 2014, and the current[br]draft (18) which is considered to be
0:37:46.080,0:37:51.590
almost final, it’s in what is[br]called ‘Last Call’ at the IETF,
0:37:51.590,0:37:57.330
was just recently in October.[br]In the security landscape
0:37:57.330,0:38:02.400
during that time you’ve seen so many[br]different types of attacks on TLS. So:
0:38:02.400,0:38:07.860
Triple Handshake, POODLE, FREAK, Logjam,[br]DROWN (there was a talk about that earlier
0:38:07.860,0:38:12.220
today), Lucky Microseconds, SLOTH.[br]All these different types of acronyms
0:38:12.220,0:38:15.550
– you may or may not have heard of –[br]have happened during the development.
0:38:15.550,0:38:21.380
So TLS 1.3 is a living[br]document, and it’s hopefully
0:38:21.380,0:38:27.561
going to be small. I mean,[br]TLS 1.2 was 79 pages.
0:38:27.561,0:38:32.521
It’s kind of a rough read, but[br]give it a shot! If you like. TLS 1.3
0:38:32.521,0:38:36.330
if you shave off a lot of the excess stuff[br]at the end is actually close. And it’s
0:38:36.330,0:38:40.980
a lot nicer read, it’s a lot more precise,[br]even though there are some interesting
0:38:40.980,0:38:46.910
features like 0-RTT, resumption. So[br]practically, how does it get written?
0:38:46.910,0:38:52.810
Well it’s, uh… Github! And a mailing list![br]So if you want to send a pull request
0:38:52.810,0:38:59.020
to this TLS working group, there it is.[br]This is actually how the draft gets defined.
0:38:59.020,0:39:04.190
And you probably want to send a message[br]to the mailing list to describe what your
0:39:04.190,0:39:09.300
change is, if you want to. I suggest if[br]anybody wants to be involved this is
0:39:09.300,0:39:14.190
pretty late. I mean it’s in ‘Last Call’…[br]But the mailing list is still open. Now
0:39:14.190,0:39:18.370
I’ve been working on this with a bunch of[br]other people, Filippo as well. We were
0:39:18.370,0:39:23.230
contributors on the draft, been working[br]for over a year on this. You can check
0:39:23.230,0:39:29.230
the Github issues to see how much work[br]has gone into it. The draft has changed
0:39:29.230,0:39:34.130
over the years and months.
0:39:34.130,0:39:38.620
E.g. Draft 9 had this very[br]complicated tree structure
0:39:38.620,0:39:43.550
for a key schedule, you can see[br]htk… all these different things
0:39:43.550,0:39:49.980
had to do with different keys in the TLS[br]handshake. And this was inspired by QUIC,
0:39:49.980,0:39:55.650
the Google protocol that Filippo mentioned[br]earlier as well as a paper called ‘OPTLS’.
0:39:55.650,0:40:00.610
And it had lots of different modes,[br]semi-static Diffie-Hellman, and this
0:40:00.610,0:40:04.950
tree-based key schedule. And over the[br]time this was widdled down from this
0:40:04.950,0:40:10.510
complicated diagram to what we have[br]now in TLS 1.3. Which is a very simple
0:40:10.510,0:40:16.330
derivation algorithm. This took a lot[br]of work to get from something big
0:40:16.330,0:40:21.670
to something small. But it’s happened![br]Other things that happened
0:40:21.670,0:40:27.230
in TLS 1.3 are sort of less substantial,[br]cryptographically, and that involves
0:40:27.230,0:40:32.550
naming! If anyone has been following[br]along, TLS 1.3 is not necessarily
0:40:32.550,0:40:38.180
the unanimous choice for the name of this[br]protocol. It’s, as Filippo mentioned, 1.0,
0:40:38.180,0:40:44.000
1.1, 1.2 are pretty small iterations[br]even on SSLv3, whereas
0:40:44.000,0:40:49.071
TLS 1.3 is quite a big change.[br]So there is a lot of options
0:40:49.071,0:40:54.950
for names! Let’s have[br]a show of hands: Who here
0:40:54.950,0:40:59.860
thinks it should be called 1.3?[br]laughs
0:40:59.860,0:41:02.030
Thanks, Filippo! Filippo laughs[br]Yeah, so, pretty good number.
0:41:02.030,0:41:07.840
How about TLS 2? Anybody?[br]Well, that actually looks like more than…
0:41:07.840,0:41:12.940
Filippo: Remember that SSLv2 is[br]a thing! And it’s a terrible thing!
0:41:12.940,0:41:18.040
Nick: You don’t want to confuse[br]that with us! So how about TLS 4?
0:41:18.040,0:41:22.520
Still a significant number of people…[br]How about TLS 2017? Yeah…[br]
0:41:22.520,0:41:25.780
Alright! TLS 7 anybody? Okay…
0:41:25.780,0:41:30.400
Filippo: TLS Millennium 2019 X?
0:41:30.400,0:41:35.410
YES! Sold![br]Nick: Alright! TLS Vista?
0:41:35.410,0:41:38.860
laughter - Nick and Filippo laugh[br]applause
0:41:38.860,0:41:44.800
Nick: Lots of options! But just as[br]a reminder, the rest of the world
0:41:44.800,0:41:50.040
doesn’t really call it TLS. This is Google[br]trends, interest over time, searching for
0:41:50.040,0:41:55.300
‘SSL vs. TLS’. SSL is really what most[br]of the world calls this protocol. So SSL
0:41:55.300,0:42:00.240
has the highest version of Version 3,[br]and that’s kind of the reason why people
0:42:00.240,0:42:05.210
thought ‘TLS 4’ was a good idea, because[br]“Oh, people are confused: 3 is higher
0:42:05.210,0:42:10.720
than 1.2, yada-yada-yada”.
0:42:10.720,0:42:14.870
This poll was not the only poll. It was[br]taken there some informal twitter polls.
0:42:14.870,0:42:20.030
“Mmm, Bacon!” was a good one,[br]52% of Ryan Hurst’s poll.
0:42:20.030,0:42:23.870
laughter
0:42:23.870,0:42:28.130
Versions are a really sticky thing in TLS.
0:42:28.130,0:42:32.780
E.g. the versions that we have of TLS[br]– if you look at them on the wire
0:42:32.780,0:42:37.640
they actually don’t match up.[br]So SSL 3 is 3.0 which does match up.
0:42:37.640,0:42:43.720
But TLS 1 is 3.1; 3.2…[br]TLS 1.2 is 3.3; and originally
0:42:43.720,0:42:49.000
I think up to Draft 16[br]of TLS 1.3 it was 3.4.
0:42:49.000,0:42:53.761
Just sort of a bumping the minor[br]version of TLS 1.2, very confusing.
0:42:53.761,0:42:58.511
But after doing some internet[br]measurement it was determined that
0:42:58.511,0:43:02.670
a lot of servers, if you send a ‘Client[br]Hello’ with ‘3.4’, it just disconnects. So
0:43:02.670,0:43:07.960
this is actually really bad, it prevents[br]browsers from being able to actually
0:43:07.960,0:43:13.080
safely downgrade. What a server is[br]supposed to do if it sees a version
0:43:13.080,0:43:18.780
higher than 3.3 is just respond with “3.3”[br]saying: “Hey, this is the best I have”.
0:43:18.780,0:43:24.880
But turns out a lot of these break.[br]So 3.3 is in the ‘Client Hello’ now, and
0:43:24.880,0:43:30.680
3.4 is negotiated as a sub[br]protocol. So this is messy.
0:43:30.680,0:43:35.610
Right? But we do balance the benefits vs.[br]complexity, and this is one of the ones
0:43:35.610,0:43:39.640
where the benefits of not having servers[br]fail outweigh the complexity added,
0:43:39.640,0:43:44.340
of adding an additional thing. And to[br]prevent this from happening in the future
0:43:44.340,0:43:48.820
David Benjamin proposed something called[br]GREASE where in every single piece of
0:43:48.820,0:43:53.920
TLS negotiation you are supposed to,[br]as a client, add some random stuff
0:43:53.920,0:43:56.980
in there, so that servers will[br]get used to seeing things
0:43:56.980,0:44:01.050
that are not versions they’re used to.[br]So, 0x8a8a. It’s all GREASE-d up!
0:44:01.050,0:44:06.320
Filippo: It’s a real thing![br]It’s a real very useful thing!
0:44:06.320,0:44:08.760
Nick: This is going to be very useful,[br]for the future, for preventing
0:44:08.760,0:44:13.850
these sorts of things. But it’s really[br]unfortunate that that had to happen.
0:44:13.850,0:44:18.830
We are running low on time, but[br]we dued to actually get involved with
0:44:18.830,0:44:23.430
getting our hands dirty. And one thing[br]the IETF really loves when developing
0:44:23.430,0:44:28.680
these standards is running code. So we[br]started with the IETF 95 Hackathon
0:44:28.680,0:44:32.950
which is in April, and managed,[br]by the end of it, to get Firefox
0:44:32.950,0:44:37.740
to load a server hosted by Cloudflare[br]over TLS 1.3. Which was a big
0:44:37.740,0:44:43.250
accomplishment at the time. We used NSS[br]which is the security library in Firefox
0:44:43.250,0:44:48.850
and ‘Mint’ which was a new version
0:44:48.850,0:44:52.890
of TLS 1.3, from scratch, written in Go.
0:44:52.890,0:44:57.640
And the result was, it worked! But[br]this was just a proof-of-concept.
0:44:57.640,0:45:02.950
Filippo: To build something that was more[br]production ready, we looked at what was
0:45:02.950,0:45:08.330
the TLS library that we were most[br]confident modifying, which unsurprisingly
0:45:08.330,0:45:13.370
wasn’t OpenSSL! So we opted to
0:45:13.370,0:45:17.990
build 1.3 on top of the Go[br]crypto/tls library, which is
0:45:17.990,0:45:24.210
in the Go language standard library.[br]The result, we call it ‘tls-tris’,
0:45:24.210,0:45:28.500
and it’s a drop-in replacement for[br]crypto/tls, and comes with this
0:45:28.500,0:45:33.970
wonderful warning that says “Do not use[br]this for the sake of everything that’s
0:45:33.970,0:45:38.990
good and just!” Now, it used to be about[br]everything, but now it’s not really
0:45:38.990,0:45:45.190
about security anymore, we got this[br]audited, but it’s still about stability.
0:45:45.190,0:45:50.510
We are working on upstreaming[br]this, which will solidify the API,
0:45:50.510,0:45:56.000
and you can follow along with the[br]upstreaming process. The Google people
0:45:56.000,0:46:00.830
were kind enough to open us a branch to do[br]the development, and it will definitely not
0:46:00.830,0:46:06.960
hit the next Go release, Go 1.8, but we[br]are looking forward to upstreaming this.
0:46:06.960,0:46:12.010
Anyway, even if you use Go,[br]deploying is hard.
0:46:12.010,0:46:17.800
The first time we deployed Tris[br]the draft number version was 13.
0:46:17.800,0:46:23.630
And to actually support browsers[br]going forward from there we had
0:46:23.630,0:46:29.140
to support multiple draft versions[br]at the same time by switching on
0:46:29.140,0:46:34.590
obscure details sometimes. And sometimes[br]had to support things that were definitely
0:46:34.590,0:46:40.030
not even drafts because[br]browsers started to… diverge.
0:46:40.030,0:46:44.970
Now, anyway, we had[br]a test matrix that would run
0:46:44.970,0:46:50.610
all our commits against all the different[br]versions of the client libraries,
0:46:50.610,0:46:54.980
and that would make sure that we are[br]always compatible with the browsers.
0:46:54.980,0:47:00.170
And these days the clients are actually[br]much more stable, and indeed
0:47:00.170,0:47:05.050
you might be already using it[br]without knowing. E.g. Chrome Beta,
0:47:05.050,0:47:11.160
the beta channel has it enabled for about[br]50% as an experiment from the Google side.
0:47:11.160,0:47:16.110
And this is how our graphs looked[br]like when we first launched,
0:47:16.110,0:47:21.560
when Firefox Nightly enabled it by default[br]and when Chrome Canary enabled it
0:47:21.560,0:47:26.510
by default. These days we are stable,[br]around 700 requests per second
0:47:26.510,0:47:30.640
carried over TLS 1.3.[br]And on our side we enabled it
0:47:30.640,0:47:36.230
for millions of our[br]websites on Cloudflare.
0:47:36.230,0:47:40.830
And, anyway, as we said,[br]the spec is a living document
0:47:40.830,0:47:46.080
and it is open. You can see it on[br]Github. The Tris implementation is there
0:47:46.080,0:47:50.860
even if it has this scary warning, and[br]the blog here is where we’ll probably
0:47:50.860,0:47:56.210
publish all the follow-up research and[br]results of this. Thank you very much and
0:47:56.210,0:47:59.990
if you have any questions please come[br]forward, I think we have a few minutes.
0:47:59.990,0:48:11.770
applause
0:48:11.770,0:48:15.690
Herald: Thank you, we have plenty[br]of time for questions. First question
0:48:15.690,0:48:19.770
goes to the Internet.
0:48:19.770,0:48:23.930
Signal Angel: The very first[br]question is of people asking if
0:48:23.930,0:48:28.160
the decision of the 0-RTT going[br]on to the application, handing it
0:48:28.160,0:48:32.450
off to the application developers,[br]if that is a very wise decision?
0:48:32.450,0:48:34.130
Filippo: laughs[br]applause
0:48:34.130,0:48:40.230
Filippo: Well… fair. So, as we said, this[br]is definitely breaking an abstraction.
0:48:40.230,0:48:45.500
So it’s NOT broken by default.[br]If you just update Go
0:48:45.500,0:48:50.791
and get TLS 1.3 you won’t[br]get any 0-RTT because
0:48:50.791,0:48:54.800
indeed it requires collaboration by the[br]application. So unless an application
0:48:54.800,0:48:59.980
knows what to do with it it just can not[br]use that and have all the security benefits
0:48:59.980,0:49:06.920
and the one round trip full[br]handshake advantages, anyway.
0:49:06.920,0:49:09.570
Herald: Ok, next question[br]is from microphone 1.
0:49:09.570,0:49:12.680
Question: With your early testing of the[br]protocol have you been able to capture
0:49:12.680,0:49:17.610
any hard numbers on what those[br]performance improvements look like?
0:49:17.610,0:49:21.170
Filippo sighs
0:49:21.170,0:49:24.580
Nick: One round trip! laughs[br]Depends how much a round trip is.
0:49:24.580,0:49:28.000
Filippo: Yeah, exactly. One round trip[br]is… I mean, I can’t tell you a number
0:49:28.000,0:49:33.250
because of course if you live in[br]San Francisco with a fast fiber it’s,
0:49:33.250,0:49:39.120
I don’t know, 3 milliseconds, 6…?[br]If you live in, I don’t know,
0:49:39.120,0:49:43.260
some country where EDGE is the only type[br]of connection you get that’s probably
0:49:43.260,0:49:47.700
around one second. I think we have an[br]average that is around… between 100
0:49:47.700,0:49:55.100
and 200 milliseconds, but we haven’t[br]like formally collected these numbers.
0:49:55.100,0:49:57.630
Herald: Ok, next question[br]from microphone 3.
0:49:57.630,0:50:01.720
Question: One remark I wanted to make is[br]that another improvement that was made
0:50:01.720,0:50:07.350
in TLS 1.3 is that they added[br]encryption to client certificates.
0:50:07.350,0:50:11.330
So the client certificates are transmitted[br]encrypted which is important
0:50:11.330,0:50:17.670
if you think about that a client will[br]move, and a dragnet surveillance entity
0:50:17.670,0:50:23.120
could track clients with this. And[br]another remark/question which might…
0:50:23.120,0:50:27.080
Herald: Questions are ended with a question[br]mark. So can you keep it please a bit short?
0:50:27.080,0:50:31.820
Question: Yeah…[br]That might be stupid so…
0:50:31.820,0:50:36.400
Does the fixed Diffie-Hellman[br]groups… wasn’t that the problem
0:50:36.400,0:50:42.890
with the LogJam attack, so… does[br]this help with LogJam attacks?
0:50:42.890,0:50:46.660
Nick: Are you referencing the[br]proposal for the banks?
0:50:46.660,0:50:49.590
Question: No no, just in general,[br]that you can pre-compute…
0:50:49.590,0:50:54.430
Nick: Right, yes, so in Logjam there was[br]a problem where there was a DH group
0:50:54.430,0:50:57.940
that was shared by a lot of different[br]servers by default. The Apache one,
0:50:57.940,0:51:03.800
which was 1024 [bit].[br]In TLS 1.3 it was restricted to
0:51:03.800,0:51:09.190
a pre-computed DH group, that’s[br]over 2000 bits, as the smallest one,
0:51:09.190,0:51:14.600
and even with all the pre-computation in[br]the world if you have a 2000 bit DH group
0:51:14.600,0:51:20.140
it’s not feasible to pre-compute[br]enough to do any type of attack.
0:51:20.140,0:51:21.990
But, yeah, that’s a very good point.
0:51:21.990,0:51:24.950
Filippo: …and since they are fixed there[br]is no way to force the protocol to use
0:51:24.950,0:51:28.940
anything else that would not be as strong.[br]Question: Okay, thanks!
0:51:28.940,0:51:32.720
Herald: Next question for microphone 4.
0:51:32.720,0:51:37.120
Question: Thanks for your talk! In the[br]abstract you mentioned that another
0:51:37.120,0:51:41.550
feature that had to be killed was SNI,
0:51:41.550,0:51:45.920
with the 0-RTT but there are ways to still[br]implement that, can you elaborate a bit?
0:51:45.920,0:51:49.670
Filippo: Yeah. So, we gave this talk[br]internally twice, and this question came
0:51:49.670,0:51:55.590
both of the times. So… laughs
0:51:55.590,0:52:01.790
So, SNI is a small parameter[br]that the client sends to the server
0:52:01.790,0:52:06.210
to say which website it is trying to[br]connect to. E.g. Cloudflare has
0:52:06.210,0:52:11.250
a lot of websites behind our machines, so[br]you have to tell us “Oh I actually want
0:52:11.250,0:52:17.230
to connect to blog.filippo.io”. Now[br]this is of course a privacy concern
0:52:17.230,0:52:22.550
because someone just looking at the bytes[br]on the wire will know what specific website
0:52:22.550,0:52:29.450
you want to connect to. Now the unfortunate[br]thing is that it has the same problem as
0:52:29.450,0:52:35.270
getting forward secrecy for the early[br]data. You send SNI in the ‘Client Hello’,
0:52:35.270,0:52:39.620
and at that time you haven’t negotiated[br]any key yet, so you don’t have anything
0:52:39.620,0:52:44.960
to encrypt it with. But if you[br]don’t send SNI in the first flight
0:52:44.960,0:52:49.140
then the server doesn’t know what[br]certificate to send, so it can’t send
0:52:49.140,0:52:53.050
the signature in the first flight! So you[br]don’t have keys. So you would have to do
0:52:53.050,0:52:59.030
a 2-round trip, and now we would[br]be back at TLS 1.2. So, alas.
0:52:59.030,0:53:03.180
That doesn’t work with[br]1-round trip handshakes.
0:53:03.180,0:53:08.820
Nick: That said, there are proposals in[br]the HTTP2 spec to allow multiplexing,
0:53:08.820,0:53:14.210
and this is ongoing work. It could be[br]possible to establish one connection
0:53:14.210,0:53:19.700
to a domain and then establish another[br]connection within the existing connection.
0:53:19.700,0:53:21.950
And that could potentially[br]protect your SNI.
0:53:21.950,0:53:25.520
Filippo: So someone looking would think[br]that you are going to blog.filippo.io but
0:53:25.520,0:53:29.480
then, once you open the connection,[br]you would be able to ask HTTP2 to also
0:53:29.480,0:53:33.200
serve you “this other website”. Thanks!
0:53:33.200,0:53:38.170
Herald: Okay, next[br]question, microphone 7,
0:53:38.170,0:53:41.240
or actually 5, sorry.
0:53:41.240,0:53:47.440
Question: You mentioned that there[br]was formal verification of TLS 1.3.
0:53:47.440,0:53:54.350
What’s the software that was used[br]to do the formal verification?
0:53:54.350,0:53:59.030
Nick: So there were several software[br]implementations and protocols…
0:53:59.030,0:54:02.650
Let’s see if I can go back… here.
0:54:02.650,0:54:06.600
So, Tamarin[Prover] is a piece of software[br]developed by Cas Cremers and others,
0:54:06.600,0:54:11.810
at Oxford and Royal Holloway.[br]miTLS is in F# I believe,
0:54:11.810,0:54:18.430
this is by INRIA.[br]And NQSB-TLS is in OCAMAL.
0:54:18.430,0:54:22.970
So several different languages were used[br]to develop these and I believe the authors
0:54:22.970,0:54:27.490
of NQSB-TLS are here…
0:54:27.490,0:54:30.960
Herald: Okay, next question, microphone 8.
0:54:30.960,0:54:36.440
Question: Hi! Thanks. Thank you for[br]your informative presentation.
0:54:36.440,0:54:42.690
SSL and TLS history is riddled with “what[br]could possibly go wrong” ideas and moments
0:54:42.690,0:54:48.810
that bit us in the ass eventually. And so[br]I guess my question is taking into account
0:54:48.810,0:54:52.740
that there’s a lot of smaller organisations[br]or smaller hosting companies etc. that
0:54:52.740,0:54:59.600
will probably get this 0-RTT thing[br]wrong. Your gut feeling? How large
0:54:59.600,0:55:04.180
a chance is there that this will indeed[br]bite us in the ass soon? Thank you.
0:55:04.180,0:55:09.990
Filippo: Ok, so, as I said I’m[br]actually vaguely sceptical
0:55:09.990,0:55:16.460
on the impact on HTTP because browsers[br]can be made to replay requests already.
0:55:16.460,0:55:21.610
And we have seen papers[br]and blog posts about it. But
0:55:21.610,0:55:25.830
no one actually went out[br]and proved that that broke
0:55:25.830,0:55:30.620
a huge percent of the internet. But to[br]be honest, I actually don’t know how to
0:55:30.620,0:55:35.990
answer you how badly we will be bit by it.[br]But remember that on the other hand
0:55:35.990,0:55:41.650
of the balance is how many still say[br]that they won’t implement TLS
0:55:41.650,0:55:45.670
because it’s “slow”. Now, no!
0:55:45.670,0:55:51.620
It’s 0-RTT, TLS is fast! Go[br]out and encrypt everything!
0:55:51.620,0:55:57.940
So those are the 2 concerns that[br]you have to balance together.
0:55:57.940,0:56:01.910
Again, my personal opinion[br]is also worth very little.
0:56:01.910,0:56:07.310
This was a decision that was made by[br]the entire community on the mailing list.
0:56:07.310,0:56:12.900
And I can assure you that everyone has[br]been really conservative with everything,
0:56:12.900,0:56:18.630
thinking even… indeed, if the name[br]would have mislead people. So,
0:56:18.630,0:56:23.910
I can’t predict the future. I can only[br]say that I hope we made the best choice
0:56:23.910,0:56:28.520
to make the most part of the[br]web the most secure we can.
0:56:28.520,0:56:32.490
Herald: Next question is from the internet.
0:56:32.490,0:56:34.610
Signal Angel, do we have another[br]question from the internet?
0:56:34.610,0:56:37.760
Signal Angel: Yes we do.
0:56:37.760,0:56:43.060
What are the major implementation[br]incompatibilities that were found
0:56:43.060,0:56:45.800
now that the actual spec is fairly close?
0:56:45.800,0:56:47.910
Herald: Can you repeat that question?
0:56:47.910,0:56:53.250
Signal Angel repeats question
0:56:53.250,0:56:59.290
Filippo: Okay. As in[br]during the drafts period?
0:56:59.290,0:57:03.450
So, some of the ones that had version[br]intolerance were mostly, I think,
0:57:03.450,0:57:06.750
middle boxes and firewalls.
0:57:06.750,0:57:12.690
Nick: There were some very large sites.[br]I think Paypal was one of them?
0:57:12.690,0:57:18.310
Filippo: Although during the process we[br]had incompatibilities for all kinds of
0:57:18.310,0:57:23.540
reasons, including one of[br]the 2 developers misspelled
0:57:23.540,0:57:28.110
the variable number.[br]laughs
0:57:28.110,0:57:32.420
During the drafts sometimes compatibility[br]broke, but there was a lot of
0:57:32.420,0:57:37.970
collaboration between client implementations[br]and server implementations on our side.
0:57:37.970,0:57:44.040
So I’m pretty happy to say that the[br]actual 1.3 implementations had a lot of
0:57:44.040,0:57:50.980
interoperability testing, and all the[br]issues were pretty quick to be killed.
0:57:50.980,0:57:54.050
Herald: Okay, next question[br]is from microphone number 1.
0:57:54.050,0:57:59.300
Question: I have 2 quick questions[br]concerning session resumption.
0:57:59.300,0:58:02.951
If you store some data on a server[br]from a session, wouldn’t that be
0:58:02.951,0:58:08.010
some kind of supercookie?[br]Is that not privacy-dangerous?
0:58:08.010,0:58:13.990
And the second question would be: what[br]about DNS load balancers or some other
0:58:13.990,0:58:21.070
huge amounts of servers where your request[br]is going to different servers every time?
0:58:21.070,0:58:28.150
Filippo: Ok, so, these are details about[br]deploying session tickets effectively.
0:58:28.150,0:58:32.950
TLS 1.3 does think about the privacy[br]concerns of session tickets; and indeed
0:58:32.950,0:58:37.650
it allows the server to send multiple[br]session tickets. So the server will still
0:58:37.650,0:58:42.470
know what client is sending it if it[br]wants to. But at least anyone looking
0:58:42.470,0:58:47.460
at the connection since they are[br]sent encrypted, not like in 1.2, and
0:58:47.460,0:58:53.171
there can be many. Anyone looking at the[br]connection will not be able to link it
0:58:53.171,0:58:57.600
back to the original connection. That’s[br]the best you can do, because if the server
0:58:57.600,0:59:02.560
and the client have to reuse some shared[br]knowledge the server has to learn about
0:59:02.560,0:59:08.240
who it was. But session tickets in 1.3[br]can’t be tracked by a passive observer,
0:59:08.240,0:59:13.010
by a third party, actually. And… when you[br]do load balancing… there is an interesting
0:59:13.010,0:59:18.750
paper about deploying session tickets,[br]but the gist is that you probably want
0:59:18.750,0:59:24.960
to figure out how clients roam between[br]your servers, and strike a balance between
0:59:24.960,0:59:30.340
having to share the session ticket[br]key so that it’s more effective, and
0:59:30.340,0:59:35.500
not sharing the session ticket key which[br]makes it harder to acquire them all.
0:59:35.500,0:59:41.610
You might want to do geographically[br]located, or in-a-single-rack…
0:59:41.610,0:59:44.540
it’s really up to the deployment.
0:59:44.540,0:59:47.480
Herald: Okay, final question[br]goes to microphone 3.
0:59:47.480,0:59:51.750
Question: I have a question regarding the[br]GREASE mechanism that is implemented
0:59:51.750,0:59:57.110
on the client side. If I understood[br]it correctly you are inserting
0:59:57.110,1:00:02.350
random version numbers of[br]not-existing TLS or SSL versions
1:00:02.350,1:00:08.640
and that way training[br]the servers to
1:00:08.640,1:00:14.480
conform to the specification. What[br]is the result of the real-world tests?
1:00:14.480,1:00:18.490
How many servers actually[br]are broken by this?
1:00:18.490,1:00:22.780
Filippo: So you would expect none because[br]after all they are all implementing 1.3
1:00:22.780,1:00:28.070
now, so that all the clients they would[br]see would already be doing GREASE. Instead
1:00:28.070,1:00:33.100
just as Google enabled GREASE I think[br]it broke… I’m not sure so I won’t say
1:00:33.100,1:00:38.330
which specific server implementation, but[br]one of the minor server implementations
1:00:38.330,1:00:41.860
was immediately detected[br]as… the Haskell one!
1:00:41.860,1:00:43.890
Nick: Right![br]Filippo: I don’t remember the name,
1:00:43.890,1:00:47.450
I can’t read Haskell, so I don’t know what[br]exactly they were doing, but they were
1:00:47.450,1:00:49.590
terminating connections because of GREASE.
1:00:49.590,1:00:53.480
Nick: And just as a note, GREASE is also[br]used in cipher negotiation and anything
1:00:53.480,1:00:58.800
that is a negotiation in TLS 1.3.[br]So this actually did break
1:00:58.800,1:01:03.020
a subset of servers, but[br]a small enough subset
1:01:03.020,1:01:06.600
that people were happy with it.
1:01:06.600,1:01:08.670
Question: Thanks![br]Nick: 2% is too high!
1:01:08.670,1:01:11.430
Herald: Thank you very much.[br]Filippo: Thank you!
1:01:11.430,1:01:20.010
applause
1:01:20.010,1:01:39.080
33C3 postroll music
1:01:39.080,1:01:43.981
subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!