0:00:00.000,0:00:18.480
35C3 preroll music
0:00:18.480,0:00:24.019
Herald-Angel: All right. Now it's my very[br]big pleasure to introduce Hanno Böck to
0:00:24.019,0:00:32.029
you. He's no stranger to the Chaos crowd.[br]He's been to several Easterheggs and at
0:00:32.029,0:00:38.500
several other Chaos events. Today he's[br]here to talk about TLS 1.3, what it's all
0:00:38.500,0:00:44.300
about how it came to be and what the[br]future of it is gonna look like. Please
0:00:44.300,0:00:57.560
give a huge applause and welcome Hanno.[br]hanno: Yeah. Okay. So today I want to talk
0:00:57.560,0:01:04.050
to you about a new version of TLS. TLS is[br]this protocol, Transport Layer Security,
0:01:04.050,0:01:09.780
which I hope everyone knows what it is.[br]It's a protocol that you can put on top of
0:01:09.780,0:01:15.990
other protocols that gives us an encrypted[br]and authenticated channel through the
0:01:15.990,0:01:25.500
generally insecure internet. We have a new[br]version since August, TLS 1.3. At first
0:01:25.500,0:01:31.130
I'd like to go a bit into the history of why we[br]have this new version, how we got there
0:01:31.130,0:01:40.750
and what design decisions were made for[br]this version. So the very first version of
0:01:40.750,0:01:47.490
SSL which it was called back then was[br]released in 1995 by Netscape and it was
0:01:47.490,0:01:54.550
quickly followed up with version 3 which[br]is still very similar to the TLS 1.2 that
0:01:54.550,0:02:01.380
we mostly use today. And then in 1999 it[br]was kind of taken over from Netscape to
0:02:01.380,0:02:05.810
the IETF, which is the Internet[br]standardization organization, and they
0:02:05.810,0:02:12.470
renamed it to TLS. And so that's kind of[br]the history. We had SSL and I've marked it
0:02:12.470,0:02:17.640
in red because these two versions are[br]broken by design. You cannot really use
0:02:17.640,0:02:22.770
them in a way that is secure these days[br]because we know vulnerabilities that are
0:02:22.770,0:02:31.080
part of the protocol. And then we had, in[br]1999 it was renamed to TLS, and TLS is
0:02:31.080,0:02:35.690
kind of still kind of OK if you do[br]everything right. But that's really
0:02:35.690,0:02:40.880
tricky. So it's kind of a dangerous[br]protocol but maybe not totally broken.
0:02:40.880,0:02:46.930
Same with TLS 1.1. TLS 1.2 is what we[br]still mostly use today and TLS 1.3 is the
0:02:46.930,0:02:52.140
new one and what you can see here for[br]example is that the the biggest gap here
0:02:52.140,0:02:59.510
is between 1.2 and 1.3, so it was a very[br]long time where we had no new development
0:02:59.510,0:03:09.161
here. You probably heard that we had[br]plenty of vulnerabilities in TLS, around
0:03:09.161,0:03:16.080
TLS and also these days, a good[br]vulnerability always has a logo and a nice
0:03:16.080,0:03:23.240
name. And I want to go into one[br]vulnerability which doesn't have a logo.
0:03:23.240,0:03:29.230
Not one of the variants. I was very[br]surprised when I realized that. That's the
0:03:29.230,0:03:35.130
so-called Padding Oracles. They are in CBC[br]mode which is the encryption we use for
0:03:35.130,0:03:43.550
the actual data encryption, the symmetric[br]data encryption. The thing is, when we
0:03:43.550,0:03:51.130
encrypt data what we usually use are so-[br]called block ciphers and they encrypt one
0:03:51.130,0:04:00.230
block off a specific size of data. It's[br]usually sixteen bytes and this CBC mode
0:04:00.230,0:04:06.970
was the common way to encrypt in past TLS[br]versions. And this is roughly how it looks
0:04:06.970,0:04:11.470
like. So we have some initialization[br]vector which should be random, but wasn't
0:04:11.470,0:04:18.930
always, but that's another story. And then[br]we encrypt a block of data and then we XOR
0:04:18.930,0:04:27.190
that encryption into the next plain text[br]and encrypt it again. Now one thing here
0:04:27.190,0:04:32.390
is that because these are blocks of data[br]and our data may not always be in sixteen
0:04:32.390,0:04:38.040
byte blocks it may just be five bytes or[br]whatever, we need to fill up that space.
0:04:38.040,0:04:47.260
So we need some kind of padding. In TLS,[br]what was done was that first of all we had
0:04:47.260,0:04:53.150
some data. Then we added a MAC, which is[br]something that guarantees the correctness
0:04:53.150,0:04:58.090
of the data, the authentication of the[br]data. And then we pad it up to a block
0:04:58.090,0:05:02.950
size and then we encrypt it. And this[br]order of things turned out to be very
0:05:02.950,0:05:10.870
problematic. So this padding is a very[br]simple method. If we have one byte to fill
0:05:10.870,0:05:17.460
up we make a 00. If we have two bytes to[br]fill up well you make 0101, three bytes
0:05:17.460,0:05:27.530
020202 and so on. So that's easy to[br]understand, right? Let's for a moment
0:05:27.530,0:05:35.240
assume a situation where an attacker can[br]manipulate data and can see whether the
0:05:35.240,0:05:42.180
server receives a bad padding or whether[br]it receives bad data, where this MAC check
0:05:42.180,0:05:52.080
goes wrong. And here is the decryption[br]with CBC mode. And what an attacker can do
0:05:52.080,0:05:57.450
here: the first thing the attacker does,[br]it throws one block away at the end, it
0:05:57.450,0:06:04.270
just blocks the transmission of that block[br]and then it changes something here. So
0:06:04.270,0:06:11.160
what we assume here is the attacker wants[br]to know this decrypted byte because it may
0:06:11.160,0:06:17.970
contain some interesting data. So what he[br]can do is he can manipulate this byte with
0:06:17.970,0:06:27.250
a guess and a byte is only 256 values a[br]byte can have. So he can guess enough
0:06:27.250,0:06:36.330
times and XOR it with this value. And if[br]you think about it if we XOR it here with
0:06:36.330,0:06:40.889
the plaintext. That means if we end up[br]with this zero here then the padding is
0:06:40.889,0:06:46.419
valid. If we end up with some garbage[br]value here, then the padding is probably
0:06:46.419,0:06:54.940
invalid. So by making enough guesses the[br]attacker can decrypt a byte here under the
0:06:54.940,0:07:01.049
condition that he learns somehow whether[br]the padding is valid or not. So he could
0:07:01.049,0:07:06.930
decrypt one byte but he can't go on. Let's[br]assume we will learn that one byte we have
0:07:06.930,0:07:15.229
decrypted it and then we can go on with[br]the next byte. So we XOR this byte on the
0:07:15.229,0:07:22.800
right with the guess with what we already[br]know that it is and with the one and. Then
0:07:22.800,0:07:30.880
we XOR this next byte with our guess and[br]also a one. And if this ends up being 0101
0:07:30.880,0:07:35.941
then again we have a valid padding. So the[br]attacker learns the next byte and he can
0:07:35.941,0:07:44.110
do this for other bytes. This was[br]originally discovered in 2002 by Sergey
0:07:44.110,0:07:51.160
Vaudenay. But it was kind of only[br]theoretical. So one thing here is that TLS
0:07:51.160,0:07:57.910
has these error messages. There are[br]different kinds of errors. And if you read
0:07:57.910,0:08:06.110
through the TLS 1.0 standard, if the[br]padding is wrong then you get this
0:08:06.110,0:08:11.060
decryption_failed error. And if the MAC is[br]wrong, so the data has some modification,
0:08:11.060,0:08:15.590
then you get this bad_record_mac error. So[br]you could say this would allow this
0:08:15.590,0:08:22.410
Padding Oracle attack because there are[br]these error messages. But the attacker
0:08:22.410,0:08:26.160
cannot see them because they are[br]encrypted. So this was kind of only a
0:08:26.160,0:08:32.880
theoretical attack which didn't really[br]work on a real TLS connection. But then
0:08:32.880,0:08:37.770
there was a later paper which made this[br]attack practical by measuring the timing
0:08:37.770,0:08:42.948
difference from these different kinds of[br]errors. And this allowed a practical
0:08:42.948,0:08:52.249
decryption of TLS traffic. Then in later[br]versions of TLS this was fixed or kind of
0:08:52.249,0:08:57.460
fixed. But there is a warning in the[br]standard which says.. So this is right
0:08:57.460,0:09:02.160
from the standard text. "This leaves a[br]small timing channel but it is not
0:09:02.160,0:09:07.170
believed to be large enough to be[br]exploitable." If you read something like
0:09:07.170,0:09:16.149
that, it sounds maybe suspicious, maybe[br]dangerous. And actually in 2013 there was
0:09:16.149,0:09:20.180
these so-called Lucky Thirteen attack[br]where a team of researchers actually
0:09:20.180,0:09:26.199
managed to exploit that small timing side[br]channel that the designers of the standard
0:09:26.199,0:09:35.209
believed was not large enough to be[br]exploitable. It is in theory possible to
0:09:35.209,0:09:39.640
implement TLS in a way that it is safe[br]from this timing attacks. But it adds a
0:09:39.640,0:09:44.670
lot of complexity to the code. If you just[br]look at when Lucky Thirteen was fixed, it
0:09:44.670,0:09:51.939
just made the code much longer and much[br]harder to understand. Then there was
0:09:51.939,0:09:57.029
another Padding Oracle which was called[br]POODLE, which was in the old version
0:09:57.029,0:10:03.999
SSLv3. This was kind of by design. So the[br]protocol was built in a way that you could
0:10:03.999,0:10:11.100
not avoid this Padding Oracle. Then it[br]turned out that there was also a kind of
0:10:11.100,0:10:18.209
TLS variation of this POODLE attack. And[br]the reason here was that the only major
0:10:18.209,0:10:26.699
change between SSLv3 and TLS 1.0 was that[br]the padding was fixed to a specific value,
0:10:26.699,0:10:30.600
where in the past it could have any value.[br]It turned out that there were TLS
0:10:30.600,0:10:36.480
implementations that were not checking[br]that, enabling this poodle attack also in
0:10:36.480,0:10:44.880
TLS. Then there was the so-called Lucky[br]Microseconds attack which was basically
0:10:44.880,0:10:50.480
the.. one of the people who has found the[br]Lucky Thirteen attack looked at
0:10:50.480,0:10:55.930
implementations and saw if they have fixed[br]Lucky Thirteen properly. They looked at
0:10:55.930,0:11:01.339
s2n, which is an SSL library from Amazon[br]and they found: "Ok, they tried to make
0:11:01.339,0:11:04.829
countermeasures against this attack but[br]these countermeasures didn't really work
0:11:04.829,0:11:13.119
and they had still a timing attack that[br]they could perform." Then there was a bug
0:11:13.119,0:11:19.660
in OpenSSL which was kind of funny because[br]when OpenSSL tried to fix this Lucky
0:11:19.660,0:11:24.700
Thirteen attack, they introduced another[br]Padding Oracle attack which was actually
0:11:24.700,0:11:34.040
much easier to exploit. We had plenty of[br]Padding Oracles. But if you remember back
0:11:34.040,0:11:39.149
what I said, for the very first attack[br]that this didn't really work in practice
0:11:39.149,0:11:46.670
in TLS, because these errors are[br]encrypted. But theoretically you could
0:11:46.670,0:11:52.200
imagine that someone creates an[br]implementation that sends errors that are
0:11:52.200,0:12:02.250
not encrypted. For example you can send a[br]TCP error or just cut the connection or
0:12:02.250,0:12:06.499
have any kind of different behavior[br]because the whole attack just relies on
0:12:06.499,0:12:13.379
the fact that you can distinguish these[br]two kinds of errors. You can find
0:12:13.379,0:12:24.079
implementations out there doing that. So[br]yeah, Padding Oracle is still an issue.
0:12:24.079,0:12:27.839
Then I want to look at another attack[br]which is a so-called Bleichenbacher
0:12:27.839,0:12:33.019
attacks and they target the RSA encryption[br]and that is kind of the asymmetric
0:12:33.019,0:12:41.430
encryption which we use at the beginning[br]of a connection to establish a shared key.
0:12:41.430,0:12:52.260
This attack was found in 1998 by Daniel[br]Bleichenbacher. If you look at the RSA
0:12:52.260,0:13:01.569
encryption before we encrypt something[br]with RSA, we do some preparations. The way
0:13:01.569,0:13:09.750
this is done and in all TLS versions is[br]these so-called PKCS #1 1.5 standard. How
0:13:09.750,0:13:15.999
this looks is: it starts with the 00 02.[br]Then we have some random data which is
0:13:15.999,0:13:21.290
just again a padding to fill up space.[br]Then we have zero which marks the end of
0:13:21.290,0:13:27.680
the pending. Then we have a version number[br]03 03, which stands for TLS 1.2. It's
0:13:27.680,0:13:33.279
totally obvious right. I'll get two[br]version numbers later. And then we have
0:13:33.279,0:13:38.779
the secret data. But the relevant thing[br]for this attack is mostly this 00 02 at
0:13:38.779,0:13:44.929
the beginning. So we know each correct[br]encrypted block, if we decrypt it, it
0:13:44.929,0:13:55.980
starts with 00 02. We may wonder if we[br]implement a TLS server and it decrypts
0:13:55.980,0:14:04.129
some data from the client and then it[br]doesn't start with 00 02: what shall I do?
0:14:04.129,0:14:07.989
And the naive thing would be: yeah of[br]course we just send an error message
0:14:07.989,0:14:14.389
because something is obviously wrong here.[br]Now this turns out to be not such a good
0:14:14.389,0:14:19.690
idea because if we do this we will tell[br]the attacker something. We will tell him
0:14:19.690,0:14:24.870
that the decrypted data does not start[br]with 00 02. So the attacker learned
0:14:24.870,0:14:30.170
something about the interval in which the[br]decrypted data is. Either it starts with
0:14:30.170,0:14:38.129
00 02 or it doesn't. And this turned out[br]to be enough to.. if you send enough
0:14:38.129,0:14:44.549
queries and modify the ciphertext you can[br]learn enough information to decrypt data.
0:14:44.549,0:14:48.669
The whole algorithm is a bit more[br]complicated but it's not that complicated.
0:14:48.669,0:14:52.809
It's relatively straightforward. It's a[br]bit of math and I didn't want to put in
0:14:52.809,0:15:01.279
any formulas but yeah. Now as I said it[br]was discovered in 1998. So TLS 1.0
0:15:01.279,0:15:07.129
introduced some countermeasures. The[br]general idea here is that if you decrypt
0:15:07.129,0:15:13.449
something and it is wrong then you're[br]supposed to replace it with a random value
0:15:13.449,0:15:19.170
and use that random value as your secret[br]and pretend nothing has happened and then
0:15:19.170,0:15:22.900
continue and then the handshake will fail[br]later on because you don't have the same
0:15:22.900,0:15:28.100
key. This prevents the attacker from[br]learning whether your data is valid or
0:15:28.100,0:15:35.109
not. In 2003 a research-team figured out[br]that the countermeasures how they were
0:15:35.109,0:15:39.839
described and TLS 1.0 were incomplete and[br]also not entirely, it was not entirely
0:15:39.839,0:15:44.779
clear how to implement them. Because[br]there's this version-thing and it was not
0:15:44.779,0:15:50.339
exactly described how to handle that. If[br]only the version is wrong. So they they
0:15:50.339,0:15:55.699
were able to make, to create an attack[br]that still worked despite this
0:15:55.699,0:16:03.970
countermeasures. So more countermeasures[br]were proposed and in 2014 there was a
0:16:03.970,0:16:09.610
paper that Java was still vulnerable to[br]Bleichenbacher-attacks in a special way
0:16:09.610,0:16:14.320
because they used some kind of decoding,[br]then raised an exception. And the
0:16:14.320,0:16:18.390
exception was long enough that you could[br]measure the timing difference. And there
0:16:18.390,0:16:23.519
was also still a small issue in OpenSSL[br]although that was not practically
0:16:23.519,0:16:32.649
exploitable. In 2016 there the so-called[br]drown-attack. And the drown-attack was a
0:16:32.649,0:16:37.519
Bleichenbacher-attack in SSL version 2.[br]Now you may wonder SSL-version 2 is this
0:16:37.519,0:16:44.499
very very old version from 1995. Is this a[br]problem? But it actually is because you
0:16:44.499,0:16:50.309
can use encrypted data from a modern TLS-[br]version, TLS 1.2, and and decrypt it with
0:16:50.309,0:16:58.850
a server that still supports SSL version[br]2. So that was the drown-attack. And then
0:16:58.850,0:17:03.519
last year I thought maybe someone should[br]check if there are still servers
0:17:03.519,0:17:08.290
vulvernable to these Bleichenbacher-[br]attacks. So I wrote a small scan tool and
0:17:08.290,0:17:14.270
started scanning, and scanned the Alexa[br]top-1000000. The first hit was
0:17:14.270,0:17:21.349
Facebook.com was vulnerable and it turned[br]out from the top-100 pages roughly 1/3
0:17:21.349,0:17:25.869
were vulnerable. And in the end we found[br]like 15 different implementations that
0:17:25.869,0:17:37.090
were vulnerable. Probably more but these[br]were the ones we know about. Yeah. And
0:17:37.090,0:17:42.260
just I think a month ago there was another[br]paper, that there also you can use cache-
0:17:42.260,0:17:48.210
sidechannels which is mostly interesting[br]if you have cloud-infrastructure where
0:17:48.210,0:17:52.180
multiple servers are running on the same[br]hardware, which you can also use to
0:17:52.180,0:18:00.200
perform these Bleichenbacher-attacks. Now[br]what I want to show you here: You cannot
0:18:00.200,0:18:05.120
read this because it's too small but this[br]is the chapters in the TLS-standard that
0:18:05.120,0:18:09.880
describe the countermeasures to these[br]Bleichenbacher-attacks. So we knew about
0:18:09.880,0:18:14.620
them since before TLS 1.2, so there was a[br]small chapter what you should do to
0:18:14.620,0:18:18.410
prevent these attacks. And then they[br]figured out: OK that's not enough. We need
0:18:18.410,0:18:25.450
to have more countermeasures, and even[br]more. So, what you can clearly see here is
0:18:25.450,0:18:31.730
it's getting more and more complicated to[br]prevent these attacks. So with every new
0:18:31.730,0:18:40.550
TLS-version we had more complexity to[br]prevent these Bleichenbacher-attacks.
0:18:40.550,0:18:45.380
These were just two examples. There were a[br]lot more attacks on TLS 1.2 and earlier
0:18:45.380,0:18:50.920
that were due to poor design choices. I've[br]named a few here: SLOTH, which was all
0:18:50.920,0:18:56.620
against weak caches, FREAK which can[br]attack issues in the handshake and
0:18:56.620,0:19:03.680
compatibility with old versions, SWEET32[br]which attacks some block-ciphers that have
0:19:03.680,0:19:08.800
a small blocksize, Triple-Handshake which[br]is a very complicated interaction of
0:19:08.800,0:19:18.160
different handshakes. The general trend[br]here was that in TLS 1.2 and earlier, if
0:19:18.160,0:19:23.151
there was a security bug, if there was a[br]vulnerability in the cryptography, what
0:19:23.151,0:19:29.110
people did was: We need a workaround for[br]the security issue. And then if this
0:19:29.110,0:19:35.340
workaround doesn't work it's not[br]sufficient. We need more workarounds. And
0:19:35.340,0:19:41.630
also we create more secure modes but we[br]still keep the old ones. And then people
0:19:41.630,0:19:45.580
can choose. We have this algorithm[br]agility. You can choose, there's the
0:19:45.580,0:19:52.460
secure algorithm, there's the less secure[br]algorithm. Take whatever you want. Which
0:19:52.460,0:19:56.240
in practice meant very often still the[br]insecure modes were used because like for
0:19:56.240,0:20:00.950
all of these things there were modes[br]available in TLS 1.2 that didn't have
0:20:00.950,0:20:09.900
these vulnerabilities. But they were[br]optional. But, and I think that is the
0:20:09.900,0:20:17.610
major change that came with TLS 1.3, was a[br]mindset-change that people said, okay if
0:20:17.610,0:20:22.300
something has vulnerabilities, if it's[br]insecure and if we have something better
0:20:22.300,0:20:29.980
then we just remove the thing that is[br]vulnerable, that is problematic. So the
0:20:29.980,0:20:35.390
main change in TLS 1.3 was that a lot of[br]things were deprecated. So we no longer
0:20:35.390,0:20:40.560
have these CBC-modes. We no longer have[br]our RC4 which is another cipher which was
0:20:40.560,0:20:48.770
problematic. We no longer have 3DES, which[br]has these small blocksizes. We still use
0:20:48.770,0:20:54.200
GCM but we no longer use it with an[br]explicit nonce, which also turned out to
0:20:54.200,0:21:00.330
be problematic. We completely remove RSA-[br]encryption. We still use RSA but only for
0:21:00.330,0:21:06.511
signatures. We remove hash-functions that[br]turned out to be insecure. We remove
0:21:06.511,0:21:13.280
Diffie-Hellman with custom parameters,[br]which was, yeah, which turned out to be
0:21:13.280,0:21:23.890
very problematic. And we removed ecliptic-[br]curves that kind of look not so secure.
0:21:23.890,0:21:31.420
But also there was something that some[br]academics looked at TLS with the more
0:21:31.420,0:21:36.380
scientific view. They tried to formally[br]understand the security protocol,
0:21:36.380,0:21:41.110
properties of this protocol and to analyze[br]them to see if they can proof some kind of
0:21:41.110,0:21:47.850
security properties of the protocol. And[br]many vulnerabilities that I mentioned
0:21:47.850,0:21:53.310
earlier were found by these researchers[br]trying to formally analyze the protocol.
0:21:53.310,0:22:01.370
But also these analyses have contributed[br]to design TLS 1.3 to make it more robust
0:22:01.370,0:22:07.270
to attacks. So this is, I think, also a[br]big change. There was a much better
0:22:07.270,0:22:12.300
collaboration between scientists who were[br]looking at the protocol and the people who
0:22:12.300,0:22:21.480
were actually writing the protocol. But[br]you may see, all the security is nice but
0:22:21.480,0:22:26.260
what we really care about or maybe some[br]people really care about is speech, right.
0:22:26.260,0:22:30.790
We want our internet to be fast. We want[br]to open our browser and immediately get
0:22:30.790,0:22:43.440
the page loaded. And TLS 1.3 also brings[br]improved speed. And I am showing here the
0:22:43.440,0:22:49.940
handshake. And this is very simplified. I[br]have kind of only added the things that
0:22:49.940,0:22:55.220
matter to make this point. But, if you[br]look at on the left, if we do a handshake
0:22:55.220,0:22:59.890
with an old TLS-version it starts that[br]this client sends a client-hello, and some
0:22:59.890,0:23:05.160
information, what version it supports,[br]what encryption modes it's supports. Then
0:23:05.160,0:23:09.810
the server sends back which encryption[br]modes it wants to use and a key
0:23:09.810,0:23:15.770
exchange. And then the client sends his[br]part of the key exchange. And the so-
0:23:15.770,0:23:19.460
called finished message and then the[br]server sends a finished message and then
0:23:19.460,0:23:27.000
the client can start sending data. In TLS[br]1.3 we have compressed this all a bit. The
0:23:27.000,0:23:32.540
client sends his client-hello and[br]immediately sends a key-exchange message.
0:23:32.540,0:23:37.550
And then the server answers with his key-[br]exchange message. And a few more things
0:23:37.550,0:23:42.840
that I left out for simplicity. But the[br]important thing is that with the second
0:23:42.840,0:23:50.300
message the client can already send data.[br]And this is the situation for a fresh
0:23:50.300,0:23:55.000
handshake. Like we have not communicated[br]before. I want to make a new connection to
0:23:55.000,0:24:02.460
a server and it goes one time back and[br]forth. And then I can send data. Which,
0:24:02.460,0:24:07.330
and in the earlier version I had two times[br]back and forth. So I can send data much
0:24:07.330,0:24:18.300
faster. So yeah, we remove one round-trip[br]from a fresh handshake. There's also
0:24:18.300,0:24:23.550
security improvements to this handshake.[br]So this is nice. We have more security and
0:24:23.550,0:24:30.230
more speed. And particularly we have[br]better security on so-called session-
0:24:30.230,0:24:37.530
resumption, which means we're reconnecting[br]using a key from a previous section. And
0:24:37.530,0:24:42.780
we also protect more data which may avoid[br]some attacks where an attacker may fiddle
0:24:42.780,0:24:48.030
with the handshake. These were more or[br]less theoretic attacks. But these are also
0:24:48.030,0:24:57.020
prevented in TLS 1.3. Yeah. So TLS has a[br]more secure and a faster handshake. And if
0:24:57.020,0:25:01.120
you want to have more details about this[br]handshake there was a talk two years ago
0:25:01.120,0:25:06.410
at this congress, which goes into this in[br]much more detail. So if this particularly
0:25:06.410,0:25:10.140
interests you you should watch that talk.[br]I've put a link here and I will put the
0:25:10.140,0:25:19.870
slides online. There's also something[br]called the zero-roundtrip-handshake. And
0:25:19.870,0:25:26.360
this is even faster. We can send data[br]right away. Now, how can we do that? This
0:25:26.360,0:25:30.740
is kind of cheating because what we need[br]here is we need to have a previous
0:25:30.740,0:25:35.450
connection. And then we have a key from a[br]previous connection, can create a new key
0:25:35.450,0:25:42.040
from that and use that to send data right[br]away. So yeah, we need a so-called
0:25:42.040,0:25:47.250
preshared-key which we have from previous[br]connection and then we can send data
0:25:47.250,0:25:58.450
without any roundtrips. So, even more[br]speed. That's nice, right. But this 0-RTT-
0:25:58.450,0:26:04.740
mode does not come for free. There is a[br]problem here with so-called replay-
0:26:04.740,0:26:11.300
attacks, which means an attacker could[br]record the data that we're sending and
0:26:11.300,0:26:16.650
then send it again. And the server may[br]think: Okay, now this request came twice.
0:26:16.650,0:26:24.480
So I'm doing twice what this request was[br]supposed to do. So there are some caveats
0:26:24.480,0:26:29.450
with 0-RTT and the standard says you[br]should only use if it's safe. It says
0:26:29.450,0:26:36.710
something like you should only use it if[br]you have a profile how to use it safely.
0:26:36.710,0:26:43.620
Now what does that mean? There, let's look[br]at https, the protocol we're using
0:26:43.620,0:26:49.280
usually. If you look into the HTTP-[br]standard it says something that a GET-
0:26:49.280,0:26:55.470
request has to be idempotent and a POST-[br]request does not have to be idempotent.
0:26:55.470,0:26:59.780
Now what does that mean? It more or less[br]means if you send a request twice it
0:26:59.780,0:27:07.460
shouldn't do anything different from just[br]sending it once. So in theory we could say
0:27:07.460,0:27:13.180
yes a GET-requests are idempotent - that[br]means they are safe for zero-roundtrip-
0:27:13.180,0:27:23.230
connections. The question is, "do web-[br]developers" ... Sorry.
0:27:23.230,0:27:30.840
applause[br]You can do a little experiment: If you
0:27:30.840,0:27:34.970
meet someone who is a web developer, ask[br]them if they know what idempotent means,
0:27:34.970,0:27:42.910
and when they can use idempotent requests[br]and when they cannot. So, in an ideal
0:27:42.910,0:27:47.750
situation where web-developers do know[br]that, we can use 0-RTT safely with TLS
0:27:47.750,0:27:57.200
1.3. 0-RTT also does not have a strong[br]forward secrecy as a normal handshake. So,
0:27:57.200,0:28:02.090
there's kind of a tradeoff here, because[br]this pre-shared key is encrypted with a
0:28:02.090,0:28:06.300
key on the server and if that key gets[br]compromised that may compromise our
0:28:06.300,0:28:14.740
connection even if the key is only leaked[br]later on. So, this looks a bit problematic
0:28:14.740,0:28:19.900
and many speculate that the future attacks[br]we'll see on TLS 1.3, that at least some
0:28:19.900,0:28:24.470
of them will focus on this 0-RTT mode,[br]because it looks like one of the more
0:28:24.470,0:28:29.060
fragile parts of the protocol. But it[br]gives us more speed., so people wanted to
0:28:29.060,0:28:37.340
have it. Maybe the good news is, this is[br]entirely optional; we don't have to use
0:28:37.340,0:28:42.890
it; and if we think this looks too[br]problematic, we can switch it off. So, if
0:28:42.890,0:28:46.880
it turns out that there are too many[br]attacks involving 0-RTT mode, we could
0:28:46.880,0:28:51.560
disable it again and use it without it. It[br]will still be faster, but not as fast as
0:28:51.560,0:29:02.710
it could be with this. Okay. Deployment:[br]Now, if we have this nice new protocol, we
0:29:02.710,0:29:07.180
not only have to make sure it's secure and[br]fast and everything, but we also have to
0:29:07.180,0:29:16.430
deploy it. And we have to deploy it on the[br]internet - on the real internet - like the
0:29:16.430,0:29:19.530
one we have out there, not some[br]theoretical internet where there are no
0:29:19.530,0:29:24.000
bugs and everyone knows how to implement[br]protocols, but the real internet with lots
0:29:24.000,0:29:32.380
of IoT devices and enterprise firewalls[br]and all these kinds of things. And now I
0:29:32.380,0:29:40.660
want to get back to this version number.[br]This may sound like a trivial thing, but
0:29:40.660,0:29:49.810
TLS 1.3 has a new version number for the[br]protocol version. Here's a Wireshark dump
0:29:49.810,0:29:55.790
from a TLS 1.3 handshake. And if you're[br]trying to look for the version number, you
0:29:55.790,0:30:02.120
will find multiple version numbers. And in[br]case you cannot see it, I have made it a
0:30:02.120,0:30:13.550
bit larger. So at the top you see[br]"Version: TLS 1.0", encoded as 0x0301.
0:30:13.550,0:30:20.150
Okay. That looks strange. Then, a few[br]lines later, you have "Version TLS: 1.2",
0:30:20.150,0:30:27.840
0x0303. But we thought this was TLS 1.3...[br]I mean it says here at the top but somehow
0:30:27.840,0:30:34.000
there are these other versions. And then[br]if you scroll further down, you will see
0:30:34.000,0:30:40.120
"Extension: supported_versions". And then[br]here it lists TLS 1.3, which is encoded as
0:30:40.120,0:30:47.480
0x0304. So, what's going on here? This[br]looks strange. So, the first thing to
0:30:47.480,0:30:51.890
realize is why do we encode these versions[br]in such a strange way; why are we not
0:30:51.890,0:31:01.340
using 0x0100 for TLS 1.0? It's TLS 1.0[br]came after SSL version 3, which kind of
0:31:01.340,0:31:08.679
makes it version 3.1; and that's how we[br]encode it. TLS 1.0 is really just SSL
0:31:08.679,0:31:17.960
version 3.1, TLS 1.1 is SSL version 3.2[br]and so on and for TLS 1.3, it's
0:31:17.960,0:31:26.260
complicated. So, the very first version[br]you saw earlier in this Wireshark dump was
0:31:26.260,0:31:31.330
the so-called record layer and this is[br]kind of a protocol inside the TLS protocol
0:31:31.330,0:31:36.640
which has its own version number, which is[br]totally meaningless but it's just there.
0:31:36.640,0:31:41.230
And it turned out, for compatibility[br]reasons, it's best to just let this on the
0:31:41.230,0:31:46.380
version of TLS 1.0 and then, we have the[br]least problems. And this is kind of...
0:31:46.380,0:31:55.290
this record layer protocol is kind of the[br]encoding of the TLS packages. Now, if we
0:31:55.290,0:32:00.300
have a new TLS version, we cannot just[br]tell everyone "tomorrow we will use TLS
0:32:00.300,0:32:05.610
1.3" and everyone has to update, because[br]we know many people won't. And so, we
0:32:05.610,0:32:09.860
somehow need to be able to deploy this new[br]version and still be compatible with
0:32:09.860,0:32:19.840
devices that only speak the old version.[br]So, let's assume we have a client that
0:32:19.840,0:32:27.510
supports TLS 1.2, and we have a server[br]that only supports TLS 1.0. How does that
0:32:27.510,0:32:34.920
work? That's an extremely complicated[br]mechanism here. So, the client connects
0:32:34.920,0:32:44.270
and says "Hello. I speak TLS 1.2". Server[br]says "Okay, I don't know TLS 1.2, but
0:32:44.270,0:32:49.960
what's the highest version I support?"[br]It's TLS 1.0, so he sents that back. And
0:32:49.960,0:32:55.720
then, they can speak TLS 1.0 and - in case[br]the client still supports that - and we
0:32:55.720,0:33:06.290
have a connection. This is very simple. I[br]would think so. So, to illustrate how you
0:33:06.290,0:33:11.320
would program something like that, you[br]would say "Yeah, if client_max_version is
0:33:11.320,0:33:16.479
smaller than than server_max_version, then[br]we use the client_max_version. Otherwise,
0:33:16.479,0:33:23.600
we use the server_max_version. So, you[br]would think that there's no way anyone
0:33:23.600,0:33:31.820
could possibly not get that right, right?[br]I mean, it's very simple. But I was saying
0:33:31.820,0:33:36.360
earlier, we were talking about the real[br]internet. So... And on the real internet,
0:33:36.360,0:33:41.360
we have enterprise products. In case you[br]don't know that, an enterprise product is
0:33:41.360,0:33:44.160
something that's very expensive and it's[br]buggy.
0:33:44.160,0:33:55.130
LaughterApplause[br]hanno: So, yeah. We will have web pages
0:33:55.130,0:34:00.660
that run with firewalls from Cisco or we[br]will have people using IBM Domino web
0:34:00.660,0:34:06.590
server and all these kinds of things. And[br]this is the TLS version negotiation in the
0:34:06.590,0:34:13.909
enterprise edition. So a client says "Yeah[br]I want to connect with TLS 1.2" and the
0:34:13.909,0:34:18.519
server says "Oh I don't support this this[br]very new version. It's from 2008. I mean
0:34:18.519,0:34:29.029
that's 10 years in Enterprise years.[br]That's very long." So the server just
0:34:29.029,0:34:33.549
sends an error if the client connects with[br]the TLS version that it doesn't know. It
0:34:33.549,0:34:38.829
doesn't implement this version negotiation[br]correctly. And this is called version
0:34:38.829,0:34:47.140
intolerance. This has happened every time[br]there was a new TLS version. Every time we
0:34:47.140,0:34:51.949
had devices that had this problem. If we[br]tried to connect with the new TLS version
0:34:51.949,0:34:54.829
they would just fail. They would send an[br]error or they would just cut the
0:34:54.829,0:35:03.460
connection or have a timeout or crash. So[br]browsers needed to handle this somehow
0:35:03.460,0:35:07.769
because the problem here is, when a[br]browser introduces new TLS version and
0:35:07.769,0:35:11.940
everything breaks, then users will blame[br]the browser and then they will say "Yeah I
0:35:11.940,0:35:15.539
will no longer use this browser, I'll now[br]switch back to Internet Explorer" or
0:35:15.539,0:35:23.890
something like that. So browsers needed to[br]handle this somehow. What the browsers did
0:35:23.890,0:35:30.049
was "Okay, we try it with the latest TLS[br]version we support. And if we get an error
0:35:30.049,0:35:35.339
we try it again with one version lower.[br]And again one version lower and eventually
0:35:35.339,0:35:41.401
we may succeed to connect." So here we[br]have a browser and we have an enterprise
0:35:41.401,0:35:49.969
server that supports TLS 1.0 and we will[br]eventually get a connection. Do you
0:35:49.969,0:35:56.040
remember POODLE I mentioned earlier? There[br]was this padding oracle in SSLv3, which
0:35:56.040,0:36:07.139
was discovered in 2014. You may wonder[br]SSLv3 which is from 1996, that's really
0:36:07.139,0:36:14.890
old. Who uses that in 2014? It was[br]deprecated for 16 years. I mean who uses
0:36:14.890,0:36:24.390
that? Windows Phone 7 used it. On this[br]Nokia phones they also never got an
0:36:24.390,0:36:35.630
update. Normal browsers and servers at[br]least used TLS 1.0. They maybe didn't use
0:36:35.630,0:36:44.839
TLS 1.2, but they used TLS 1.0. But we[br]have these browsers that are trying to
0:36:44.839,0:36:51.400
reconnect if there's an error. And so what[br]an attacker could do is that the attacker
0:36:51.400,0:36:58.470
wants to exploit SSLv3. So he just blocks[br]all connections with the newer TLS version
0:36:58.470,0:37:05.660
and therefore forces the client to go into[br]SSLv3. And then he can exploit this attack
0:37:05.660,0:37:18.819
that only works on SSLv3. These downgrades[br]are causing security issues. What do we do
0:37:18.819,0:37:24.930
now? We could add another work workaround.[br]There was a standard called SCSV which
0:37:24.930,0:37:31.789
basically gives the server a way to tell[br]the client that it's not broken. It says
0:37:31.789,0:37:40.470
"hey, I have this kind of special cipher[br]suite" which tells the client "hey, if you
0:37:40.470,0:37:46.010
did these strange downgrades here, please[br]don't do that. I'm a well behaving
0:37:46.010,0:37:51.869
server." So we had a workaround for broken[br]servers and then we needed another
0:37:51.869,0:37:57.020
workaround for the security issues caused[br]by those workarounds. But at some points
0:37:57.020,0:38:02.079
even enterprise servers mostly had fixed[br]this version intolerance issues and
0:38:02.079,0:38:10.099
browsers stopped doing these downgrades.[br]Attacks like POODLE no longer worked.
0:38:10.099,0:38:15.849
However I just said they fixed it. No of[br]course they have not fixed it. I mean they
0:38:15.849,0:38:21.311
fixed it for TLS 1.2. But of course they[br]did not fix it for future TLS versions
0:38:21.311,0:38:28.650
because they were not around yet. This TLS[br]1.3, we would get version intolerance
0:38:28.650,0:38:33.130
again and breaking servers and would have[br]to introduce downgrades again and all the
0:38:33.130,0:38:42.109
nice security would not be very helpful.[br]The TLS working group realized that and
0:38:42.109,0:38:48.220
redesigned the handshake. It was[br]redesigned in a way that the old version
0:38:48.220,0:38:53.389
fields still said that we are connecting[br]with TLS 1.2 and then we introduce an
0:38:53.389,0:39:00.200
extension, supported_versions, which[br]signals the support for all the TLS
0:39:00.200,0:39:04.829
versions we can speak and which signals[br]support for TLS 1.3 and possibly for
0:39:04.829,0:39:12.720
future versions. Now at this point you may[br]wonder if we'll have version intolerance
0:39:12.720,0:39:18.430
with this new extension, once TLS 1.4 gets[br]out because the server may be implemented
0:39:18.430,0:39:23.019
that it sends an error if it sees an[br]unknown version in this new version
0:39:23.019,0:39:31.619
extension. David Benjamin from Google[br]thought about this and said "Yeah we have
0:39:31.619,0:39:36.710
to do something about that. We have to[br]improve the future compatibility for
0:39:36.710,0:39:44.839
future TLS versions." And he invented this[br]GREASE mechanism. The idea here is, a
0:39:44.839,0:39:50.070
server should just ignore unknown versions[br]in this extension. He gets a list of TLS
0:39:50.070,0:39:53.900
versions and if there's one in there that[br]he doesn't know about, he should just
0:39:53.900,0:40:00.859
ignore it and then connect with one of the[br]versions he knows about. So we could kind
0:40:00.859,0:40:07.430
of try to train servers to actually do[br]that. And the idea here is we're just
0:40:07.430,0:40:12.980
sending random bogus TLS versions that are[br]reserved values that will never be used
0:40:12.980,0:40:17.979
for a real TLS version. But we can just[br]randomly add them to this extension in
0:40:17.979,0:40:22.470
order to make sure that if a server[br]implements this incorrectly, they will
0:40:22.470,0:40:27.049
hopefully recognize that early because[br]there will be connection failures with
0:40:27.049,0:40:40.869
normal browsers. The hope here is if[br]enterprise vendors will implement a broken
0:40:40.869,0:40:45.089
version negotiation, they will hopefully[br]notice that before they ship the product
0:40:45.089,0:40:51.790
and then it can no longer be updated[br]because that's how the Internet works. So
0:40:51.790,0:40:55.839
we have this new version negotiation[br]mechanism we no longer need these
0:40:55.839,0:41:00.229
downgrades and we have this GREASE[br]mechanism to make it future proof. So now
0:41:00.229,0:41:17.481
we can ship TLS 1.3, right? Then there was[br]this middle box issue. Oh sorry, that's a
0:41:17.481,0:41:25.669
wrong year. It must be 2016, sorry. In[br]2016, in summer, TLS 1.3 was almost
0:41:25.669,0:41:32.940
finished. But then it took almost another[br]year till it got out. Oh sorry, I mixed up
0:41:32.940,0:41:41.420
the years. It's correct. In 2017, when TLS[br]1.3 was almost finished, but it took until
0:41:41.420,0:41:48.529
2018 until it was actually finished. The[br]reason for that was that when browser
0:41:48.529,0:41:54.660
vendors implemented a draft version of TLS[br]1.3, they noticed a lot of connection
0:41:54.660,0:42:00.780
failures. And the reason for these[br]connection failures turned out, were
0:42:00.780,0:42:05.159
devices that were trying to analyze the[br]traffic and trying to be smart. And they
0:42:05.159,0:42:09.010
thought "OK this is something that looks[br]very strange. It doesn't look like a TLS
0:42:09.010,0:42:16.039
package how we're used to it. So let's[br]just drop it, yeah?" So "Yeah, this is a
0:42:16.039,0:42:22.889
strange TLS package, I don't know what[br]to do with this, I'll drop it." These were
0:42:22.889,0:42:26.480
largely passive middle boxes. So we're not[br]talking about things like man in the
0:42:26.480,0:42:30.069
middle devices that are intercepting a TLS[br]connection but just something like a
0:42:30.069,0:42:33.859
router, where you would expect it just[br]forwards traffic. But it tries to be
0:42:33.859,0:42:38.690
smart, it tries to do advanced security[br]enterprise. I don't know. And they were
0:42:38.690,0:42:46.940
dropping traffic that looked like TLS 1.3[br]Then the browser vendors proposed some
0:42:46.940,0:42:56.910
changes to TLS 1.3 so it looks more like[br]TLS 1.2. The main thing was, they
0:42:56.910,0:43:03.460
introduced some bogus messages from TLS[br]1.2 that were supposed to be ignored. So
0:43:03.460,0:43:08.490
one such message is the so-called[br]ChangeCipherSpec message in TLS 1.2, which
0:43:08.490,0:43:15.720
originally didn't exist in 1.3 due to this[br]new handshake design. This message in 1.2,
0:43:15.720,0:43:22.980
it signals that everything from now on is[br]encrypted. The idea was "okay, if we sent
0:43:22.980,0:43:28.359
a bogus ChangeCipherSpec message early in[br]the handshake, then maybe this would
0:43:28.359,0:43:32.560
confuse those devices, thinking everything[br]after that is encrypted and they cannot
0:43:32.560,0:43:38.349
analyze it." And it turned out this[br]worked. A lot of this reduced the
0:43:38.349,0:43:45.089
connection failures a lot. There are a few[br]other things. And then eventually the
0:43:45.089,0:43:52.339
failure rates got low enough that browsers[br]thought "Okay, now we can deploy this."
0:43:52.339,0:44:00.309
There were a few more issues. This is a[br]Pixma printer from Canon. These things
0:44:00.309,0:44:06.420
have an HTTPS server. They have network[br]support. And we have to talk about these
0:44:06.420,0:44:16.390
people here. If you remember the Snowden[br]relations, one of the things that got
0:44:16.390,0:44:20.180
highlighted there was that there's a[br]random number generator called Dual EC
0:44:20.180,0:44:25.710
DRBG. And that has a backdoor and[br]basically these days everyone believes
0:44:25.710,0:44:30.289
this is a backdoor by the NSA and they[br]have some secret keys so they can predict
0:44:30.289,0:44:39.660
what random values this RNG will output.[br]Also what was in the Snowden documents was
0:44:39.660,0:44:44.580
that at some point the NSA offered 10[br]million dollars to RSA security, so they
0:44:44.580,0:44:55.509
implement this RNG. Then there was a[br]proposal, a draft, for a TLS extension,
0:44:55.509,0:45:02.979
called Extended Random, that adds some[br]extra random numbers to the TLS handshake.
0:45:02.979,0:45:08.190
Why? It wasn't really clear like it was[br]just "Yeah we can do this." It was just a
0:45:08.190,0:45:12.299
proposal. I mean everyone can write a[br]proposal for a new extension, it was never
0:45:12.299,0:45:20.609
finalized, but it was out there. And in[br]2014, a research team looked closer at
0:45:20.609,0:45:29.420
this Dual EC RNG and figured out that if[br]you use this ER extension then it's much
0:45:29.420,0:45:39.290
easier to exploit this backdoor in this[br]RNG. And coincidentally RSA's TLS library,
0:45:39.290,0:45:45.329
BSAFE, also contains support for that[br]extension. But it was switched off. They
0:45:45.329,0:45:48.809
didn't find any implementations that[br]actually used it. So it was thought of
0:45:48.809,0:45:53.539
"okay, this was no big deal, all right".[br]But actually it seems these these Canon
0:45:53.539,0:46:00.729
printers, they had enabled this extension.[br]They use this RSA BSAFE library and
0:46:00.729,0:46:08.040
enabled this ER extension, which was only[br]a draft. And so as ER was only a draft, it
0:46:08.040,0:46:13.809
had no official extension number. So such[br]a TLS extension has a number so that the
0:46:13.809,0:46:19.089
server knows what kind of extension this[br]is. And for this implementation they just
0:46:19.089,0:46:24.059
used the next available number. And it[br]turned out that this number collided with
0:46:24.059,0:46:32.990
one of the mandatory extensions that TLS[br]1.3 introduced. So these these Canon
0:46:32.990,0:46:36.319
printers could not interpret that new[br]extension. They thought this is this
0:46:36.319,0:46:45.289
Extended Random and it didn't make any[br]sense, and so you had connection failures.
0:46:45.289,0:46:50.050
In the TLS protocol they just gave this[br]extension a new number and then this no
0:46:50.050,0:46:58.009
longer happened. There were many more such[br]issues and they continue to show up. For
0:46:58.009,0:47:02.859
example recently, Java, which is like also[br]very popular in enterprise environments,
0:47:02.859,0:47:06.910
it now ships with TLS 1.3 support but it[br]doesn't really work. So you have
0:47:06.910,0:47:16.579
connection failures there. Now with all[br]these deployment issues, what about future
0:47:16.579,0:47:20.569
TLS versions? Will we have all that again?[br]And we have this GREASE mechanism and it
0:47:20.569,0:47:25.220
helps a bit like it prevents this version[br]intolerance issues but it doesn't prevent
0:47:25.220,0:47:32.349
these more complicated middle box issues.[br]There was a proposal from David Benjamin
0:47:32.349,0:47:36.099
from Google who said "Yeah, maybe we[br]should just, every few months, like every
0:47:36.099,0:47:40.989
two or three months, ship a new temporary[br]TLS version which we will use for three
0:47:40.989,0:47:47.770
months and then we will deprecate it again[br]to just constantly change the protocol so
0:47:47.770,0:47:51.150
that the Internet gets used to the fact[br]that new protocols get introduced."
0:47:51.150,0:47:56.920
Laughter[br]My prediction here is that these
0:47:56.920,0:48:01.030
deployment issues are going to get worse.[br]I mean, we know now that they exist and we
0:48:01.030,0:48:08.230
kind of have some ideas how to prevent[br]them, but if you go to enterprise security
0:48:08.230,0:48:13.859
conferences, you will know that the latest[br]trend in enterprise security is this thing
0:48:13.859,0:48:19.410
called artificial intelligence: We use[br]machine learning and fancy algorithms to
0:48:19.410,0:48:27.809
detect bad stuff. And that worries me. And[br]here's a blog post from Cisco, where they
0:48:27.809,0:48:32.569
want to use machine learning to detect bad[br]TLS traffic, because they see all this
0:48:32.569,0:48:37.220
traffic is encrypted and we can no longer[br]analyze it, we don't know if malware in
0:48:37.220,0:48:42.769
there, so let's use some machine learning;[br]it will detect bad traffic. So, what I'm
0:48:42.769,0:48:48.099
very worried that will happen here is that[br]the next generation of TLS deployment
0:48:48.099,0:48:53.319
issues will be AI-supported TLS[br]intolerance issues and it may be much
0:48:53.319,0:49:04.130
harder to fix and analyze. Speaking of[br]enterprise environments, one of the very
0:49:04.130,0:49:11.689
early changes in TLS 1.3 was that it[br]removed the RSA encryption handshake. One
0:49:11.689,0:49:15.259
reason was that it doesn't have forward[br]secrecy. The other was these, all these
0:49:15.259,0:49:23.150
Bleichenbacher attacks that I talked about[br]earlier. And then, there came an email to
0:49:23.150,0:49:31.190
the TLS working group from the banking[br]industry and I quote: "I recently learned
0:49:31.190,0:49:34.719
of a proposed change that would affect[br]many of my organization's member
0:49:34.719,0:49:40.170
institutions: the deprecation of the RSA[br]key exchange. Deprecation of the RSA key
0:49:40.170,0:49:44.140
exchange in TLS 1.3 will cause significant[br]problems for financial institutions,
0:49:44.140,0:49:48.600
almost all of whom are running TLS[br]internally and have significant, security-
0:49:48.600,0:49:54.869
critical investments in out-of-band TLS[br]decryption." What it basically means is,
0:49:54.869,0:49:59.119
they are using TLS for some connection;[br]they have some device in the middle that
0:49:59.119,0:50:05.869
is decrypting the traffic and analyzing it[br]somehow which - if they do it internally -
0:50:05.869,0:50:11.789
it's okay, but this no longer works with[br]TLS 1.3, because we always negotiate a new
0:50:11.789,0:50:20.900
key for each connection and it's no longer[br]possible to have the static decryption.
0:50:20.900,0:50:25.970
There was an answer from Kenny Patterson,[br]he's a professor from London, he said: "My
0:50:25.970,0:50:29.359
view concerning your request: no.[br]Rationale: We're trying to build a more
0:50:29.359,0:50:37.469
secure internet."[br]Applause
0:50:37.469,0:50:41.239
"You're a bit late to the party. We're[br]metaphorically speaking at the stage of
0:50:41.239,0:50:46.049
emptying the ash trays and hunting for the[br]not quite empty beer cans. More exactly,
0:50:46.049,0:50:50.559
we are at draft 15 and RSA key transport[br]disappeared from the spec about a dozen
0:50:50.559,0:50:55.619
drafts ago. I know the banking industry is[br]usually a bit slow off the mark, but this
0:50:55.619,0:51:00.700
takes the biscuit." Okay.[br]Laughter
0:51:00.700,0:51:07.900
There were several proposals then to add a[br]visibility mode to TLS 1.3, which would in
0:51:07.900,0:51:13.800
another way allow these connections that[br]could be passively observed and decrypted,
0:51:13.800,0:51:18.509
but they were all rejected and the general[br]opinion in the TLS working group was that
0:51:18.509,0:51:23.979
the goal of monitoring traffic content is[br]just fundamentally not the goal of TLS.
0:51:23.979,0:51:31.210
The goal of TLS is to have an encrypted[br]channel that no one else can read. The
0:51:31.210,0:51:37.900
industry eventually went to ETSI, which is[br]the European technology standardization
0:51:37.900,0:51:43.589
organization, and they recently published[br]something called Enterprise TLS...
0:51:43.589,0:51:51.369
Laughter[br]...which modifies TLS 1.3 in a way that it
0:51:51.369,0:51:57.880
would allow these decryptions. The IETF[br]protested against that and primarily
0:51:57.880,0:52:02.979
because of the... they used the name TLS,[br]because it sounds like this is some
0:52:02.979,0:52:08.359
addition to TLS or something, and[br]apparently ETSI has previously promised to
0:52:08.359,0:52:14.340
them that they would not use the name TLS[br]and then they named it Enterprise TLS.
0:52:14.340,0:52:23.950
Okay, but yeah... TLS 1.3 is finished. You[br]can start using it. You should update your
0:52:23.950,0:52:29.799
servers so that they use it. Your browser[br]probably already supports it. So, in
0:52:29.799,0:52:41.170
summary: TLS 1.3 deprecates many insecure[br]constructions. It's faster and deploying
0:52:41.170,0:52:47.889
new things on the internet is a mess. So,[br]yeah. That's it. And I think we have a few
0:52:47.889,0:52:59.599
minutes for questions.[br]Applause
0:52:59.599,0:53:03.610
Herald: Alright, yeah. As Hanno mentioned, we[br]have 6 minutes or so for questions. We
0:53:03.610,0:53:07.750
have 5 microphones in the room. So, if you[br]want to ask a question, hurry up to one of
0:53:07.750,0:53:11.749
the microphones and please make sure to[br]ask a short, concise question, so that we
0:53:11.749,0:53:16.180
can get as many in as we can possibly can.[br]Maybe, you just go ahead over there. Mic
0:53:16.180,0:53:18.250
2.[br]Mic 2: Thank you very much for this
0:53:18.250,0:53:23.925
interesting talk. Is there a way to[br]prevent the uses of this Enterprise TLS?
0:53:23.925,0:53:27.489
Hanno: The question is if there is a way[br]to prevent the use of that Enterprise TLS.
0:53:27.489,0:53:33.210
Yes, there is, because the basic idea is[br]that they will use a static Diffie-Hellman
0:53:33.210,0:53:38.349
key exchange and if you just connect twice[br]and see that they are using the same
0:53:38.349,0:53:43.210
again, then you may reject that. Although[br]the problem is, some servers may also use
0:53:43.210,0:53:52.410
that for optimization. So, there are[br]longer discussions on this question, so...
0:53:52.410,0:53:57.489
I cannot fully answer it, but there more[br]or less... there are options.
0:53:57.489,0:54:00.470
Herald: Alright. Before we go to the next[br]question, a quick request for all the
0:54:00.470,0:54:05.019
people leaving the room: Please do so as[br]quietly as possible, so we can finish this
0:54:05.019,0:54:10.609
Q&A in peace and don't have all this noise[br]going on. Mic 3, please.
0:54:10.609,0:54:16.740
Mic 3: Hi. I was wondering about the[br]replay attacks. Why didn't they implement
0:54:16.740,0:54:21.860
something like sequence numbers into the[br]TLS protocol?
0:54:21.860,0:54:25.160
Hanno: Yeah. There is something like that[br]in there. The problem is, you sometimes
0:54:25.160,0:54:30.270
have a situation where you have multiple[br]TLS termination points - for example, if
0:54:30.270,0:54:34.110
you have a CDN network that is[br]internationally distributed - and you may
0:54:34.110,0:54:40.449
not be able to keep state across all of[br]them.
0:54:40.449,0:54:44.390
Herald: Alright. Then, let's take a[br]question from our viewers in the internet.
0:54:44.390,0:54:50.269
The signal angel, please.[br]Signal angel: Alright. Binarystrike asks:
0:54:50.269,0:54:55.329
"With regards to TLS 1.3 in the[br]enterprise, shouldn't we move away from
0:54:55.329,0:55:00.739
perimeter interception devices to also[br]putting control on the end point, like we
0:55:00.739,0:55:09.630
would have in a zero-trust environment?"[br]Hanno: So, in my opinion, yes. But, there
0:55:09.630,0:55:14.730
are many people in the enterise security[br]industry who think that this is not
0:55:14.730,0:55:20.269
feasible. But, I mean, discussion about[br]network design, that would be a whole
0:55:20.269,0:55:24.869
other talk. Yeah.[br]Herald: Alright. Then, let's take a
0:55:24.869,0:55:29.749
question from mic 4.[br]Mic 4: Yeah. It's also related to the
0:55:29.749,0:55:37.429
Enterprise TLS. The browser can connect to[br]an Enterprise TLS server without any
0:55:37.429,0:55:41.199
problems?[br]Hanno: Yeah. So, it's built that it's
0:55:41.199,0:55:46.589
compatible with the existing TLS protocol.[br]Mic 4: Okay, thanks.
0:55:46.589,0:55:50.049
Hanno: And the reason of whether you can[br]avoid that or not, that's really a more
0:55:50.049,0:55:54.279
complicated discussion, that would kind of[br]be a whole sub-talk, so I cannot answer
0:55:54.279,0:55:58.829
this in a minute, but come to me later if[br]you are interested in details.
0:55:58.829,0:56:01.679
Herald: Alright. Then, let's take another[br]question from the interwebs.
0:56:01.679,0:56:06.450
Signal Angel: We have one more question[br]from IRC: "Would you recommend
0:56:06.450,0:56:14.750
inserting bogus values into handshakes to[br]train implementors?"
0:56:14.750,0:56:18.710
Hanno: I mean that what I said what is[br]done, that's actually what browsers are
0:56:18.710,0:56:23.739
doing, and I think this is a good idea. I[br]just think that this covers only a small
0:56:23.739,0:56:29.339
fraction of these deployment issues.[br]Herald: Okay, we still have plenty of
0:56:29.339,0:56:34.819
time, so let's go to mic 2 please.[br]Mic 2: Yeah, as you said, we have still a
0:56:34.819,0:56:40.929
lot of dirty workarounds concerning TLS[br]1.3 and all the implementatons in the
0:56:40.929,0:56:51.789
browers and so on. Is there a way to make,[br]like, a requirement for the TLS 1.3 or 1.4
0:56:51.789,0:57:01.319
compliance to meet some compliance to the[br]standard? So you have like a test you can
0:57:01.319,0:57:05.950
perform, a self-test or something like[br]that and if you pass that you are allowed
0:57:05.950,0:57:16.440
to use the TLS 1.3 logo or 1.4 logo.[br]Hanno: You can do that in theory. The
0:57:16.440,0:57:23.190
problem is you don't really want to have a[br]certification regime that people like have
0:57:23.190,0:57:28.859
to ask for a logo to be able to be allowed[br]to implement TLS. and I mean that's kind
0:57:28.859,0:57:32.530
of one of the downsides of the open[br]architecture of the Internet, right? We
0:57:32.530,0:57:36.419
allow everyone to put devices on the[br]Internet, so we kind of have to live with
0:57:36.419,0:57:43.819
that. And there's no TLS police, so, we[br]kind of have no way of preventing people
0:57:43.819,0:57:49.209
to use broken TLS implementations. And I[br]mean people won't care if they have a logo
0:57:49.209,0:57:54.539
for it or not, right?[br]Herald: Alright, let's go to mic 5 all the
0:57:54.539,0:57:58.749
way in the back there.[br]Mic 5: Okay. I have a question about
0:57:58.749,0:58:05.569
Shor's algorithm and TLS 1.3, because[br]since quantum computing is getting very
0:58:05.569,0:58:10.529
popular lately and there are a lot of[br]improvements in the industries, so what's
0:58:10.529,0:58:16.410
the current situation regarding TLS 1.3[br]and all those quantum-based algorithms
0:58:16.410,0:58:21.719
that break the complexity into polynomial[br]times?
0:58:21.719,0:58:26.950
Hanno: There's no major change here. So,[br]with TLS 1.3 you still are using
0:58:26.950,0:58:31.880
algorithms that can be broken with quantum[br]computers if you have a quantum computer.
0:58:31.880,0:58:36.430
Which currently you don't, but you may[br]have in the future. There is work done on
0:58:36.430,0:58:42.420
standardizing future algorithms that are[br]safe from quantum attacks, but that's kind
0:58:42.420,0:58:47.029
of in an early stage. And there was an[br]experiment by Google to introduce a
0:58:47.029,0:58:53.719
quantum-safe handshake, but they only ran[br]it for a few months. But, I think we will
0:58:53.719,0:58:57.410
see extensions within the next few years[br]that will introduce quantum-safe
0:58:57.410,0:59:03.369
algorithms, but right now there's no[br]change from TLS 1.2 to 1.3. Both can be
0:59:03.369,0:59:07.530
attacked with quantum computers.[br]Herald: Okay, so I think we are getting to
0:59:07.530,0:59:11.630
our last or second to last question, so[br]let's go to mic 3, I think you've been
0:59:11.630,0:59:16.939
waiting the longest.[br]Mic 3: Okay. In older versions of TLS
0:59:16.939,0:59:23.490
there was a problem for small devices such[br]as IoT and the industrial devices. Has
0:59:23.490,0:59:30.519
there been a change in 1.3 to allow them[br]to participate?
0:59:30.519,0:59:33.310
Hanno: I mean I'm not sure what entirely[br]you mean with the problem, I mean...
0:59:33.310,0:59:37.900
Mic 3: Of performance, of performance.[br]Hanno: ...of course TLS needs some... the
0:59:37.900,0:59:43.859
performance issues of TLS have usually[br]been overstated. So even in a relatively
0:59:43.859,0:59:50.260
low-power device you can implement the[br]crypto. I mean the whole protocol is
0:59:50.260,0:59:55.200
relatively complex and you need to[br]implement it somehow, but I don't think
0:59:55.200,0:59:59.930
that's such a big issue anymore because[br]even IoT devices have relatively powerfull
0:59:59.930,1:00:05.210
processors these days.[br]Herald: Okay, alright, that concludes our
1:00:05.210,1:00:10.349
Q&A, unfortunately we are out of time. So[br]please give a huge round of applause for
1:00:10.349,1:00:12.049
this great talk.
1:00:12.049,1:00:15.039
applause
1:00:15.039,1:00:20.195
35C3 postroll music
1:00:20.195,1:00:37.711
subtitles created by c3subtitles.de[br]in the year 2019. Join, and help us!