[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:18.48,Default,,0000,0000,0000,,{\i1}35C3 preroll music{\i0}
Dialogue: 0,0:00:18.48,0:00:24.02,Default,,0000,0000,0000,,Herald-Angel: All right. Now it's my very\Nbig pleasure to introduce Hanno Böck to
Dialogue: 0,0:00:24.02,0:00:32.03,Default,,0000,0000,0000,,you. He's no stranger to the Chaos crowd.\NHe's been to several Easterheggs and at
Dialogue: 0,0:00:32.03,0:00:38.50,Default,,0000,0000,0000,,several other Chaos events. Today he's\Nhere to talk about TLS 1.3, what it's all
Dialogue: 0,0:00:38.50,0:00:44.30,Default,,0000,0000,0000,,about how it came to be and what the\Nfuture of it is gonna look like. Please
Dialogue: 0,0:00:44.30,0:00:57.56,Default,,0000,0000,0000,,give a huge applause and welcome Hanno.\Nhanno: Yeah. Okay. So today I want to talk
Dialogue: 0,0:00:57.56,0:01:04.05,Default,,0000,0000,0000,,to you about a new version of TLS. TLS is\Nthis protocol, Transport Layer Security,
Dialogue: 0,0:01:04.05,0:01:09.78,Default,,0000,0000,0000,,which I hope everyone knows what it is.\NIt's a protocol that you can put on top of
Dialogue: 0,0:01:09.78,0:01:15.99,Default,,0000,0000,0000,,other protocols that gives us an encrypted\Nand authenticated channel through the
Dialogue: 0,0:01:15.99,0:01:25.50,Default,,0000,0000,0000,,generally insecure internet. We have a new\Nversion since August, TLS 1.3. At first
Dialogue: 0,0:01:25.50,0:01:31.13,Default,,0000,0000,0000,,I'd like to go a bit into the history of why we\Nhave this new version, how we got there
Dialogue: 0,0:01:31.13,0:01:40.75,Default,,0000,0000,0000,,and what design decisions were made for\Nthis version. So the very first version of
Dialogue: 0,0:01:40.75,0:01:47.49,Default,,0000,0000,0000,,SSL which it was called back then was\Nreleased in 1995 by Netscape and it was
Dialogue: 0,0:01:47.49,0:01:54.55,Default,,0000,0000,0000,,quickly followed up with version 3 which\Nis still very similar to the TLS 1.2 that
Dialogue: 0,0:01:54.55,0:02:01.38,Default,,0000,0000,0000,,we mostly use today. And then in 1999 it\Nwas kind of taken over from Netscape to
Dialogue: 0,0:02:01.38,0:02:05.81,Default,,0000,0000,0000,,the IETF, which is the Internet\Nstandardization organization, and they
Dialogue: 0,0:02:05.81,0:02:12.47,Default,,0000,0000,0000,,renamed it to TLS. And so that's kind of\Nthe history. We had SSL and I've marked it
Dialogue: 0,0:02:12.47,0:02:17.64,Default,,0000,0000,0000,,in red because these two versions are\Nbroken by design. You cannot really use
Dialogue: 0,0:02:17.64,0:02:22.77,Default,,0000,0000,0000,,them in a way that is secure these days\Nbecause we know vulnerabilities that are
Dialogue: 0,0:02:22.77,0:02:31.08,Default,,0000,0000,0000,,part of the protocol. And then we had, in\N1999 it was renamed to TLS, and TLS is
Dialogue: 0,0:02:31.08,0:02:35.69,Default,,0000,0000,0000,,kind of still kind of OK if you do\Neverything right. But that's really
Dialogue: 0,0:02:35.69,0:02:40.88,Default,,0000,0000,0000,,tricky. So it's kind of a dangerous\Nprotocol but maybe not totally broken.
Dialogue: 0,0:02:40.88,0:02:46.93,Default,,0000,0000,0000,,Same with TLS 1.1. TLS 1.2 is what we\Nstill mostly use today and TLS 1.3 is the
Dialogue: 0,0:02:46.93,0:02:52.14,Default,,0000,0000,0000,,new one and what you can see here for\Nexample is that the the biggest gap here
Dialogue: 0,0:02:52.14,0:02:59.51,Default,,0000,0000,0000,,is between 1.2 and 1.3, so it was a very\Nlong time where we had no new development
Dialogue: 0,0:02:59.51,0:03:09.16,Default,,0000,0000,0000,,here. You probably heard that we had\Nplenty of vulnerabilities in TLS, around
Dialogue: 0,0:03:09.16,0:03:16.08,Default,,0000,0000,0000,,TLS and also these days, a good\Nvulnerability always has a logo and a nice
Dialogue: 0,0:03:16.08,0:03:23.24,Default,,0000,0000,0000,,name. And I want to go into one\Nvulnerability which doesn't have a logo.
Dialogue: 0,0:03:23.24,0:03:29.23,Default,,0000,0000,0000,,Not one of the variants. I was very\Nsurprised when I realized that. That's the
Dialogue: 0,0:03:29.23,0:03:35.13,Default,,0000,0000,0000,,so-called Padding Oracles. They are in CBC\Nmode which is the encryption we use for
Dialogue: 0,0:03:35.13,0:03:43.55,Default,,0000,0000,0000,,the actual data encryption, the symmetric\Ndata encryption. The thing is, when we
Dialogue: 0,0:03:43.55,0:03:51.13,Default,,0000,0000,0000,,encrypt data what we usually use are so-\Ncalled block ciphers and they encrypt one
Dialogue: 0,0:03:51.13,0:04:00.23,Default,,0000,0000,0000,,block off a specific size of data. It's\Nusually sixteen bytes and this CBC mode
Dialogue: 0,0:04:00.23,0:04:06.97,Default,,0000,0000,0000,,was the common way to encrypt in past TLS\Nversions. And this is roughly how it looks
Dialogue: 0,0:04:06.97,0:04:11.47,Default,,0000,0000,0000,,like. So we have some initialization\Nvector which should be random, but wasn't
Dialogue: 0,0:04:11.47,0:04:18.93,Default,,0000,0000,0000,,always, but that's another story. And then\Nwe encrypt a block of data and then we XOR
Dialogue: 0,0:04:18.93,0:04:27.19,Default,,0000,0000,0000,,that encryption into the next plain text\Nand encrypt it again. Now one thing here
Dialogue: 0,0:04:27.19,0:04:32.39,Default,,0000,0000,0000,,is that because these are blocks of data\Nand our data may not always be in sixteen
Dialogue: 0,0:04:32.39,0:04:38.04,Default,,0000,0000,0000,,byte blocks it may just be five bytes or\Nwhatever, we need to fill up that space.
Dialogue: 0,0:04:38.04,0:04:47.26,Default,,0000,0000,0000,,So we need some kind of padding. In TLS,\Nwhat was done was that first of all we had
Dialogue: 0,0:04:47.26,0:04:53.15,Default,,0000,0000,0000,,some data. Then we added a MAC, which is\Nsomething that guarantees the correctness
Dialogue: 0,0:04:53.15,0:04:58.09,Default,,0000,0000,0000,,of the data, the authentication of the\Ndata. And then we pad it up to a block
Dialogue: 0,0:04:58.09,0:05:02.95,Default,,0000,0000,0000,,size and then we encrypt it. And this\Norder of things turned out to be very
Dialogue: 0,0:05:02.95,0:05:10.87,Default,,0000,0000,0000,,problematic. So this padding is a very\Nsimple method. If we have one byte to fill
Dialogue: 0,0:05:10.87,0:05:17.46,Default,,0000,0000,0000,,up we make a 00. If we have two bytes to\Nfill up well you make 0101, three bytes
Dialogue: 0,0:05:17.46,0:05:27.53,Default,,0000,0000,0000,,020202 and so on. So that's easy to\Nunderstand, right? Let's for a moment
Dialogue: 0,0:05:27.53,0:05:35.24,Default,,0000,0000,0000,,assume a situation where an attacker can\Nmanipulate data and can see whether the
Dialogue: 0,0:05:35.24,0:05:42.18,Default,,0000,0000,0000,,server receives a bad padding or whether\Nit receives bad data, where this MAC check
Dialogue: 0,0:05:42.18,0:05:52.08,Default,,0000,0000,0000,,goes wrong. And here is the decryption\Nwith CBC mode. And what an attacker can do
Dialogue: 0,0:05:52.08,0:05:57.45,Default,,0000,0000,0000,,here: the first thing the attacker does,\Nit throws one block away at the end, it
Dialogue: 0,0:05:57.45,0:06:04.27,Default,,0000,0000,0000,,just blocks the transmission of that block\Nand then it changes something here. So
Dialogue: 0,0:06:04.27,0:06:11.16,Default,,0000,0000,0000,,what we assume here is the attacker wants\Nto know this decrypted byte because it may
Dialogue: 0,0:06:11.16,0:06:17.97,Default,,0000,0000,0000,,contain some interesting data. So what he\Ncan do is he can manipulate this byte with
Dialogue: 0,0:06:17.97,0:06:27.25,Default,,0000,0000,0000,,a guess and a byte is only 256 values a\Nbyte can have. So he can guess enough
Dialogue: 0,0:06:27.25,0:06:36.33,Default,,0000,0000,0000,,times and XOR it with this value. And if\Nyou think about it if we XOR it here with
Dialogue: 0,0:06:36.33,0:06:40.89,Default,,0000,0000,0000,,the plaintext. That means if we end up\Nwith this zero here then the padding is
Dialogue: 0,0:06:40.89,0:06:46.42,Default,,0000,0000,0000,,valid. If we end up with some garbage\Nvalue here, then the padding is probably
Dialogue: 0,0:06:46.42,0:06:54.94,Default,,0000,0000,0000,,invalid. So by making enough guesses the\Nattacker can decrypt a byte here under the
Dialogue: 0,0:06:54.94,0:07:01.05,Default,,0000,0000,0000,,condition that he learns somehow whether\Nthe padding is valid or not. So he could
Dialogue: 0,0:07:01.05,0:07:06.93,Default,,0000,0000,0000,,decrypt one byte but he can't go on. Let's\Nassume we will learn that one byte we have
Dialogue: 0,0:07:06.93,0:07:15.23,Default,,0000,0000,0000,,decrypted it and then we can go on with\Nthe next byte. So we XOR this byte on the
Dialogue: 0,0:07:15.23,0:07:22.80,Default,,0000,0000,0000,,right with the guess with what we already\Nknow that it is and with the one and. Then
Dialogue: 0,0:07:22.80,0:07:30.88,Default,,0000,0000,0000,,we XOR this next byte with our guess and\Nalso a one. And if this ends up being 0101
Dialogue: 0,0:07:30.88,0:07:35.94,Default,,0000,0000,0000,,then again we have a valid padding. So the\Nattacker learns the next byte and he can
Dialogue: 0,0:07:35.94,0:07:44.11,Default,,0000,0000,0000,,do this for other bytes. This was\Noriginally discovered in 2002 by Sergey
Dialogue: 0,0:07:44.11,0:07:51.16,Default,,0000,0000,0000,,Vaudenay. But it was kind of only\Ntheoretical. So one thing here is that TLS
Dialogue: 0,0:07:51.16,0:07:57.91,Default,,0000,0000,0000,,has these error messages. There are\Ndifferent kinds of errors. And if you read
Dialogue: 0,0:07:57.91,0:08:06.11,Default,,0000,0000,0000,,through the TLS 1.0 standard, if the\Npadding is wrong then you get this
Dialogue: 0,0:08:06.11,0:08:11.06,Default,,0000,0000,0000,,decryption_failed error. And if the MAC is\Nwrong, so the data has some modification,
Dialogue: 0,0:08:11.06,0:08:15.59,Default,,0000,0000,0000,,then you get this bad_record_mac error. So\Nyou could say this would allow this
Dialogue: 0,0:08:15.59,0:08:22.41,Default,,0000,0000,0000,,Padding Oracle attack because there are\Nthese error messages. But the attacker
Dialogue: 0,0:08:22.41,0:08:26.16,Default,,0000,0000,0000,,cannot see them because they are\Nencrypted. So this was kind of only a
Dialogue: 0,0:08:26.16,0:08:32.88,Default,,0000,0000,0000,,theoretical attack which didn't really\Nwork on a real TLS connection. But then
Dialogue: 0,0:08:32.88,0:08:37.77,Default,,0000,0000,0000,,there was a later paper which made this\Nattack practical by measuring the timing
Dialogue: 0,0:08:37.77,0:08:42.95,Default,,0000,0000,0000,,difference from these different kinds of\Nerrors. And this allowed a practical
Dialogue: 0,0:08:42.95,0:08:52.25,Default,,0000,0000,0000,,decryption of TLS traffic. Then in later\Nversions of TLS this was fixed or kind of
Dialogue: 0,0:08:52.25,0:08:57.46,Default,,0000,0000,0000,,fixed. But there is a warning in the\Nstandard which says.. So this is right
Dialogue: 0,0:08:57.46,0:09:02.16,Default,,0000,0000,0000,,from the standard text. "This leaves a\Nsmall timing channel but it is not
Dialogue: 0,0:09:02.16,0:09:07.17,Default,,0000,0000,0000,,believed to be large enough to be\Nexploitable." If you read something like
Dialogue: 0,0:09:07.17,0:09:16.15,Default,,0000,0000,0000,,that, it sounds maybe suspicious, maybe\Ndangerous. And actually in 2013 there was
Dialogue: 0,0:09:16.15,0:09:20.18,Default,,0000,0000,0000,,these so-called Lucky Thirteen attack\Nwhere a team of researchers actually
Dialogue: 0,0:09:20.18,0:09:26.20,Default,,0000,0000,0000,,managed to exploit that small timing side\Nchannel that the designers of the standard
Dialogue: 0,0:09:26.20,0:09:35.21,Default,,0000,0000,0000,,believed was not large enough to be\Nexploitable. It is in theory possible to
Dialogue: 0,0:09:35.21,0:09:39.64,Default,,0000,0000,0000,,implement TLS in a way that it is safe\Nfrom this timing attacks. But it adds a
Dialogue: 0,0:09:39.64,0:09:44.67,Default,,0000,0000,0000,,lot of complexity to the code. If you just\Nlook at when Lucky Thirteen was fixed, it
Dialogue: 0,0:09:44.67,0:09:51.94,Default,,0000,0000,0000,,just made the code much longer and much\Nharder to understand. Then there was
Dialogue: 0,0:09:51.94,0:09:57.03,Default,,0000,0000,0000,,another Padding Oracle which was called\NPOODLE, which was in the old version
Dialogue: 0,0:09:57.03,0:10:03.100,Default,,0000,0000,0000,,SSLv3. This was kind of by design. So the\Nprotocol was built in a way that you could
Dialogue: 0,0:10:03.100,0:10:11.10,Default,,0000,0000,0000,,not avoid this Padding Oracle. Then it\Nturned out that there was also a kind of
Dialogue: 0,0:10:11.10,0:10:18.21,Default,,0000,0000,0000,,TLS variation of this POODLE attack. And\Nthe reason here was that the only major
Dialogue: 0,0:10:18.21,0:10:26.70,Default,,0000,0000,0000,,change between SSLv3 and TLS 1.0 was that\Nthe padding was fixed to a specific value,
Dialogue: 0,0:10:26.70,0:10:30.60,Default,,0000,0000,0000,,where in the past it could have any value.\NIt turned out that there were TLS
Dialogue: 0,0:10:30.60,0:10:36.48,Default,,0000,0000,0000,,implementations that were not checking\Nthat, enabling this poodle attack also in
Dialogue: 0,0:10:36.48,0:10:44.88,Default,,0000,0000,0000,,TLS. Then there was the so-called Lucky\NMicroseconds attack which was basically
Dialogue: 0,0:10:44.88,0:10:50.48,Default,,0000,0000,0000,,the.. one of the people who has found the\NLucky Thirteen attack looked at
Dialogue: 0,0:10:50.48,0:10:55.93,Default,,0000,0000,0000,,implementations and saw if they have fixed\NLucky Thirteen properly. They looked at
Dialogue: 0,0:10:55.93,0:11:01.34,Default,,0000,0000,0000,,s2n, which is an SSL library from Amazon\Nand they found: "Ok, they tried to make
Dialogue: 0,0:11:01.34,0:11:04.83,Default,,0000,0000,0000,,countermeasures against this attack but\Nthese countermeasures didn't really work
Dialogue: 0,0:11:04.83,0:11:13.12,Default,,0000,0000,0000,,and they had still a timing attack that\Nthey could perform." Then there was a bug
Dialogue: 0,0:11:13.12,0:11:19.66,Default,,0000,0000,0000,,in OpenSSL which was kind of funny because\Nwhen OpenSSL tried to fix this Lucky
Dialogue: 0,0:11:19.66,0:11:24.70,Default,,0000,0000,0000,,Thirteen attack, they introduced another\NPadding Oracle attack which was actually
Dialogue: 0,0:11:24.70,0:11:34.04,Default,,0000,0000,0000,,much easier to exploit. We had plenty of\NPadding Oracles. But if you remember back
Dialogue: 0,0:11:34.04,0:11:39.15,Default,,0000,0000,0000,,what I said, for the very first attack\Nthat this didn't really work in practice
Dialogue: 0,0:11:39.15,0:11:46.67,Default,,0000,0000,0000,,in TLS, because these errors are\Nencrypted. But theoretically you could
Dialogue: 0,0:11:46.67,0:11:52.20,Default,,0000,0000,0000,,imagine that someone creates an\Nimplementation that sends errors that are
Dialogue: 0,0:11:52.20,0:12:02.25,Default,,0000,0000,0000,,not encrypted. For example you can send a\NTCP error or just cut the connection or
Dialogue: 0,0:12:02.25,0:12:06.50,Default,,0000,0000,0000,,have any kind of different behavior\Nbecause the whole attack just relies on
Dialogue: 0,0:12:06.50,0:12:13.38,Default,,0000,0000,0000,,the fact that you can distinguish these\Ntwo kinds of errors. You can find
Dialogue: 0,0:12:13.38,0:12:24.08,Default,,0000,0000,0000,,implementations out there doing that. So\Nyeah, Padding Oracle is still an issue.
Dialogue: 0,0:12:24.08,0:12:27.84,Default,,0000,0000,0000,,Then I want to look at another attack\Nwhich is a so-called Bleichenbacher
Dialogue: 0,0:12:27.84,0:12:33.02,Default,,0000,0000,0000,,attacks and they target the RSA encryption\Nand that is kind of the asymmetric
Dialogue: 0,0:12:33.02,0:12:41.43,Default,,0000,0000,0000,,encryption which we use at the beginning\Nof a connection to establish a shared key.
Dialogue: 0,0:12:41.43,0:12:52.26,Default,,0000,0000,0000,,This attack was found in 1998 by Daniel\NBleichenbacher. If you look at the RSA
Dialogue: 0,0:12:52.26,0:13:01.57,Default,,0000,0000,0000,,encryption before we encrypt something\Nwith RSA, we do some preparations. The way
Dialogue: 0,0:13:01.57,0:13:09.75,Default,,0000,0000,0000,,this is done and in all TLS versions is\Nthese so-called PKCS #1 1.5 standard. How
Dialogue: 0,0:13:09.75,0:13:15.100,Default,,0000,0000,0000,,this looks is: it starts with the 00 02.\NThen we have some random data which is
Dialogue: 0,0:13:15.100,0:13:21.29,Default,,0000,0000,0000,,just again a padding to fill up space.\NThen we have zero which marks the end of
Dialogue: 0,0:13:21.29,0:13:27.68,Default,,0000,0000,0000,,the pending. Then we have a version number\N03 03, which stands for TLS 1.2. It's
Dialogue: 0,0:13:27.68,0:13:33.28,Default,,0000,0000,0000,,totally obvious right. I'll get two\Nversion numbers later. And then we have
Dialogue: 0,0:13:33.28,0:13:38.78,Default,,0000,0000,0000,,the secret data. But the relevant thing\Nfor this attack is mostly this 00 02 at
Dialogue: 0,0:13:38.78,0:13:44.93,Default,,0000,0000,0000,,the beginning. So we know each correct\Nencrypted block, if we decrypt it, it
Dialogue: 0,0:13:44.93,0:13:55.98,Default,,0000,0000,0000,,starts with 00 02. We may wonder if we\Nimplement a TLS server and it decrypts
Dialogue: 0,0:13:55.98,0:14:04.13,Default,,0000,0000,0000,,some data from the client and then it\Ndoesn't start with 00 02: what shall I do?
Dialogue: 0,0:14:04.13,0:14:07.99,Default,,0000,0000,0000,,And the naive thing would be: yeah of\Ncourse we just send an error message
Dialogue: 0,0:14:07.99,0:14:14.39,Default,,0000,0000,0000,,because something is obviously wrong here.\NNow this turns out to be not such a good
Dialogue: 0,0:14:14.39,0:14:19.69,Default,,0000,0000,0000,,idea because if we do this we will tell\Nthe attacker something. We will tell him
Dialogue: 0,0:14:19.69,0:14:24.87,Default,,0000,0000,0000,,that the decrypted data does not start\Nwith 00 02. So the attacker learned
Dialogue: 0,0:14:24.87,0:14:30.17,Default,,0000,0000,0000,,something about the interval in which the\Ndecrypted data is. Either it starts with
Dialogue: 0,0:14:30.17,0:14:38.13,Default,,0000,0000,0000,,00 02 or it doesn't. And this turned out\Nto be enough to.. if you send enough
Dialogue: 0,0:14:38.13,0:14:44.55,Default,,0000,0000,0000,,queries and modify the ciphertext you can\Nlearn enough information to decrypt data.
Dialogue: 0,0:14:44.55,0:14:48.67,Default,,0000,0000,0000,,The whole algorithm is a bit more\Ncomplicated but it's not that complicated.
Dialogue: 0,0:14:48.67,0:14:52.81,Default,,0000,0000,0000,,It's relatively straightforward. It's a\Nbit of math and I didn't want to put in
Dialogue: 0,0:14:52.81,0:15:01.28,Default,,0000,0000,0000,,any formulas but yeah. Now as I said it\Nwas discovered in 1998. So TLS 1.0
Dialogue: 0,0:15:01.28,0:15:07.13,Default,,0000,0000,0000,,introduced some countermeasures. The\Ngeneral idea here is that if you decrypt
Dialogue: 0,0:15:07.13,0:15:13.45,Default,,0000,0000,0000,,something and it is wrong then you're\Nsupposed to replace it with a random value
Dialogue: 0,0:15:13.45,0:15:19.17,Default,,0000,0000,0000,,and use that random value as your secret\Nand pretend nothing has happened and then
Dialogue: 0,0:15:19.17,0:15:22.90,Default,,0000,0000,0000,,continue and then the handshake will fail\Nlater on because you don't have the same
Dialogue: 0,0:15:22.90,0:15:28.10,Default,,0000,0000,0000,,key. This prevents the attacker from\Nlearning whether your data is valid or
Dialogue: 0,0:15:28.10,0:15:35.11,Default,,0000,0000,0000,,not. In 2003 a research-team figured out\Nthat the countermeasures how they were
Dialogue: 0,0:15:35.11,0:15:39.84,Default,,0000,0000,0000,,described and TLS 1.0 were incomplete and\Nalso not entirely, it was not entirely
Dialogue: 0,0:15:39.84,0:15:44.78,Default,,0000,0000,0000,,clear how to implement them. Because\Nthere's this version-thing and it was not
Dialogue: 0,0:15:44.78,0:15:50.34,Default,,0000,0000,0000,,exactly described how to handle that. If\Nonly the version is wrong. So they they
Dialogue: 0,0:15:50.34,0:15:55.70,Default,,0000,0000,0000,,were able to make, to create an attack\Nthat still worked despite this
Dialogue: 0,0:15:55.70,0:16:03.97,Default,,0000,0000,0000,,countermeasures. So more countermeasures\Nwere proposed and in 2014 there was a
Dialogue: 0,0:16:03.97,0:16:09.61,Default,,0000,0000,0000,,paper that Java was still vulnerable to\NBleichenbacher-attacks in a special way
Dialogue: 0,0:16:09.61,0:16:14.32,Default,,0000,0000,0000,,because they used some kind of decoding,\Nthen raised an exception. And the
Dialogue: 0,0:16:14.32,0:16:18.39,Default,,0000,0000,0000,,exception was long enough that you could\Nmeasure the timing difference. And there
Dialogue: 0,0:16:18.39,0:16:23.52,Default,,0000,0000,0000,,was also still a small issue in OpenSSL\Nalthough that was not practically
Dialogue: 0,0:16:23.52,0:16:32.65,Default,,0000,0000,0000,,exploitable. In 2016 there the so-called\Ndrown-attack. And the drown-attack was a
Dialogue: 0,0:16:32.65,0:16:37.52,Default,,0000,0000,0000,,Bleichenbacher-attack in SSL version 2.\NNow you may wonder SSL-version 2 is this
Dialogue: 0,0:16:37.52,0:16:44.50,Default,,0000,0000,0000,,very very old version from 1995. Is this a\Nproblem? But it actually is because you
Dialogue: 0,0:16:44.50,0:16:50.31,Default,,0000,0000,0000,,can use encrypted data from a modern TLS-\Nversion, TLS 1.2, and and decrypt it with
Dialogue: 0,0:16:50.31,0:16:58.85,Default,,0000,0000,0000,,a server that still supports SSL version\N2. So that was the drown-attack. And then
Dialogue: 0,0:16:58.85,0:17:03.52,Default,,0000,0000,0000,,last year I thought maybe someone should\Ncheck if there are still servers
Dialogue: 0,0:17:03.52,0:17:08.29,Default,,0000,0000,0000,,vulvernable to these Bleichenbacher-\Nattacks. So I wrote a small scan tool and
Dialogue: 0,0:17:08.29,0:17:14.27,Default,,0000,0000,0000,,started scanning, and scanned the Alexa\Ntop-1000000. The first hit was
Dialogue: 0,0:17:14.27,0:17:21.35,Default,,0000,0000,0000,,Facebook.com was vulnerable and it turned\Nout from the top-100 pages roughly 1/3
Dialogue: 0,0:17:21.35,0:17:25.87,Default,,0000,0000,0000,,were vulnerable. And in the end we found\Nlike 15 different implementations that
Dialogue: 0,0:17:25.87,0:17:37.09,Default,,0000,0000,0000,,were vulnerable. Probably more but these\Nwere the ones we know about. Yeah. And
Dialogue: 0,0:17:37.09,0:17:42.26,Default,,0000,0000,0000,,just I think a month ago there was another\Npaper, that there also you can use cache-
Dialogue: 0,0:17:42.26,0:17:48.21,Default,,0000,0000,0000,,sidechannels which is mostly interesting\Nif you have cloud-infrastructure where
Dialogue: 0,0:17:48.21,0:17:52.18,Default,,0000,0000,0000,,multiple servers are running on the same\Nhardware, which you can also use to
Dialogue: 0,0:17:52.18,0:18:00.20,Default,,0000,0000,0000,,perform these Bleichenbacher-attacks. Now\Nwhat I want to show you here: You cannot
Dialogue: 0,0:18:00.20,0:18:05.12,Default,,0000,0000,0000,,read this because it's too small but this\Nis the chapters in the TLS-standard that
Dialogue: 0,0:18:05.12,0:18:09.88,Default,,0000,0000,0000,,describe the countermeasures to these\NBleichenbacher-attacks. So we knew about
Dialogue: 0,0:18:09.88,0:18:14.62,Default,,0000,0000,0000,,them since before TLS 1.2, so there was a\Nsmall chapter what you should do to
Dialogue: 0,0:18:14.62,0:18:18.41,Default,,0000,0000,0000,,prevent these attacks. And then they\Nfigured out: OK that's not enough. We need
Dialogue: 0,0:18:18.41,0:18:25.45,Default,,0000,0000,0000,,to have more countermeasures, and even\Nmore. So, what you can clearly see here is
Dialogue: 0,0:18:25.45,0:18:31.73,Default,,0000,0000,0000,,it's getting more and more complicated to\Nprevent these attacks. So with every new
Dialogue: 0,0:18:31.73,0:18:40.55,Default,,0000,0000,0000,,TLS-version we had more complexity to\Nprevent these Bleichenbacher-attacks.
Dialogue: 0,0:18:40.55,0:18:45.38,Default,,0000,0000,0000,,These were just two examples. There were a\Nlot more attacks on TLS 1.2 and earlier
Dialogue: 0,0:18:45.38,0:18:50.92,Default,,0000,0000,0000,,that were due to poor design choices. I've\Nnamed a few here: SLOTH, which was all
Dialogue: 0,0:18:50.92,0:18:56.62,Default,,0000,0000,0000,,against weak caches, FREAK which can\Nattack issues in the handshake and
Dialogue: 0,0:18:56.62,0:19:03.68,Default,,0000,0000,0000,,compatibility with old versions, SWEET32\Nwhich attacks some block-ciphers that have
Dialogue: 0,0:19:03.68,0:19:08.80,Default,,0000,0000,0000,,a small blocksize, Triple-Handshake which\Nis a very complicated interaction of
Dialogue: 0,0:19:08.80,0:19:18.16,Default,,0000,0000,0000,,different handshakes. The general trend\Nhere was that in TLS 1.2 and earlier, if
Dialogue: 0,0:19:18.16,0:19:23.15,Default,,0000,0000,0000,,there was a security bug, if there was a\Nvulnerability in the cryptography, what
Dialogue: 0,0:19:23.15,0:19:29.11,Default,,0000,0000,0000,,people did was: We need a workaround for\Nthe security issue. And then if this
Dialogue: 0,0:19:29.11,0:19:35.34,Default,,0000,0000,0000,,workaround doesn't work it's not\Nsufficient. We need more workarounds. And
Dialogue: 0,0:19:35.34,0:19:41.63,Default,,0000,0000,0000,,also we create more secure modes but we\Nstill keep the old ones. And then people
Dialogue: 0,0:19:41.63,0:19:45.58,Default,,0000,0000,0000,,can choose. We have this algorithm\Nagility. You can choose, there's the
Dialogue: 0,0:19:45.58,0:19:52.46,Default,,0000,0000,0000,,secure algorithm, there's the less secure\Nalgorithm. Take whatever you want. Which
Dialogue: 0,0:19:52.46,0:19:56.24,Default,,0000,0000,0000,,in practice meant very often still the\Ninsecure modes were used because like for
Dialogue: 0,0:19:56.24,0:20:00.95,Default,,0000,0000,0000,,all of these things there were modes\Navailable in TLS 1.2 that didn't have
Dialogue: 0,0:20:00.95,0:20:09.90,Default,,0000,0000,0000,,these vulnerabilities. But they were\Noptional. But, and I think that is the
Dialogue: 0,0:20:09.90,0:20:17.61,Default,,0000,0000,0000,,major change that came with TLS 1.3, was a\Nmindset-change that people said, okay if
Dialogue: 0,0:20:17.61,0:20:22.30,Default,,0000,0000,0000,,something has vulnerabilities, if it's\Ninsecure and if we have something better
Dialogue: 0,0:20:22.30,0:20:29.98,Default,,0000,0000,0000,,then we just remove the thing that is\Nvulnerable, that is problematic. So the
Dialogue: 0,0:20:29.98,0:20:35.39,Default,,0000,0000,0000,,main change in TLS 1.3 was that a lot of\Nthings were deprecated. So we no longer
Dialogue: 0,0:20:35.39,0:20:40.56,Default,,0000,0000,0000,,have these CBC-modes. We no longer have\Nour RC4 which is another cipher which was
Dialogue: 0,0:20:40.56,0:20:48.77,Default,,0000,0000,0000,,problematic. We no longer have 3DES, which\Nhas these small blocksizes. We still use
Dialogue: 0,0:20:48.77,0:20:54.20,Default,,0000,0000,0000,,GCM but we no longer use it with an\Nexplicit nonce, which also turned out to
Dialogue: 0,0:20:54.20,0:21:00.33,Default,,0000,0000,0000,,be problematic. We completely remove RSA-\Nencryption. We still use RSA but only for
Dialogue: 0,0:21:00.33,0:21:06.51,Default,,0000,0000,0000,,signatures. We remove hash-functions that\Nturned out to be insecure. We remove
Dialogue: 0,0:21:06.51,0:21:13.28,Default,,0000,0000,0000,,Diffie-Hellman with custom parameters,\Nwhich was, yeah, which turned out to be
Dialogue: 0,0:21:13.28,0:21:23.89,Default,,0000,0000,0000,,very problematic. And we removed ecliptic-\Ncurves that kind of look not so secure.
Dialogue: 0,0:21:23.89,0:21:31.42,Default,,0000,0000,0000,,But also there was something that some\Nacademics looked at TLS with the more
Dialogue: 0,0:21:31.42,0:21:36.38,Default,,0000,0000,0000,,scientific view. They tried to formally\Nunderstand the security protocol,
Dialogue: 0,0:21:36.38,0:21:41.11,Default,,0000,0000,0000,,properties of this protocol and to analyze\Nthem to see if they can proof some kind of
Dialogue: 0,0:21:41.11,0:21:47.85,Default,,0000,0000,0000,,security properties of the protocol. And\Nmany vulnerabilities that I mentioned
Dialogue: 0,0:21:47.85,0:21:53.31,Default,,0000,0000,0000,,earlier were found by these researchers\Ntrying to formally analyze the protocol.
Dialogue: 0,0:21:53.31,0:22:01.37,Default,,0000,0000,0000,,But also these analyses have contributed\Nto design TLS 1.3 to make it more robust
Dialogue: 0,0:22:01.37,0:22:07.27,Default,,0000,0000,0000,,to attacks. So this is, I think, also a\Nbig change. There was a much better
Dialogue: 0,0:22:07.27,0:22:12.30,Default,,0000,0000,0000,,collaboration between scientists who were\Nlooking at the protocol and the people who
Dialogue: 0,0:22:12.30,0:22:21.48,Default,,0000,0000,0000,,were actually writing the protocol. But\Nyou may see, all the security is nice but
Dialogue: 0,0:22:21.48,0:22:26.26,Default,,0000,0000,0000,,what we really care about or maybe some\Npeople really care about is speech, right.
Dialogue: 0,0:22:26.26,0:22:30.79,Default,,0000,0000,0000,,We want our internet to be fast. We want\Nto open our browser and immediately get
Dialogue: 0,0:22:30.79,0:22:43.44,Default,,0000,0000,0000,,the page loaded. And TLS 1.3 also brings\Nimproved speed. And I am showing here the
Dialogue: 0,0:22:43.44,0:22:49.94,Default,,0000,0000,0000,,handshake. And this is very simplified. I\Nhave kind of only added the things that
Dialogue: 0,0:22:49.94,0:22:55.22,Default,,0000,0000,0000,,matter to make this point. But, if you\Nlook at on the left, if we do a handshake
Dialogue: 0,0:22:55.22,0:22:59.89,Default,,0000,0000,0000,,with an old TLS-version it starts that\Nthis client sends a client-hello, and some
Dialogue: 0,0:22:59.89,0:23:05.16,Default,,0000,0000,0000,,information, what version it supports,\Nwhat encryption modes it's supports. Then
Dialogue: 0,0:23:05.16,0:23:09.81,Default,,0000,0000,0000,,the server sends back which encryption\Nmodes it wants to use and a key
Dialogue: 0,0:23:09.81,0:23:15.77,Default,,0000,0000,0000,,exchange. And then the client sends his\Npart of the key exchange. And the so-
Dialogue: 0,0:23:15.77,0:23:19.46,Default,,0000,0000,0000,,called finished message and then the\Nserver sends a finished message and then
Dialogue: 0,0:23:19.46,0:23:27.00,Default,,0000,0000,0000,,the client can start sending data. In TLS\N1.3 we have compressed this all a bit. The
Dialogue: 0,0:23:27.00,0:23:32.54,Default,,0000,0000,0000,,client sends his client-hello and\Nimmediately sends a key-exchange message.
Dialogue: 0,0:23:32.54,0:23:37.55,Default,,0000,0000,0000,,And then the server answers with his key-\Nexchange message. And a few more things
Dialogue: 0,0:23:37.55,0:23:42.84,Default,,0000,0000,0000,,that I left out for simplicity. But the\Nimportant thing is that with the second
Dialogue: 0,0:23:42.84,0:23:50.30,Default,,0000,0000,0000,,message the client can already send data.\NAnd this is the situation for a fresh
Dialogue: 0,0:23:50.30,0:23:55.00,Default,,0000,0000,0000,,handshake. Like we have not communicated\Nbefore. I want to make a new connection to
Dialogue: 0,0:23:55.00,0:24:02.46,Default,,0000,0000,0000,,a server and it goes one time back and\Nforth. And then I can send data. Which,
Dialogue: 0,0:24:02.46,0:24:07.33,Default,,0000,0000,0000,,and in the earlier version I had two times\Nback and forth. So I can send data much
Dialogue: 0,0:24:07.33,0:24:18.30,Default,,0000,0000,0000,,faster. So yeah, we remove one round-trip\Nfrom a fresh handshake. There's also
Dialogue: 0,0:24:18.30,0:24:23.55,Default,,0000,0000,0000,,security improvements to this handshake.\NSo this is nice. We have more security and
Dialogue: 0,0:24:23.55,0:24:30.23,Default,,0000,0000,0000,,more speed. And particularly we have\Nbetter security on so-called session-
Dialogue: 0,0:24:30.23,0:24:37.53,Default,,0000,0000,0000,,resumption, which means we're reconnecting\Nusing a key from a previous section. And
Dialogue: 0,0:24:37.53,0:24:42.78,Default,,0000,0000,0000,,we also protect more data which may avoid\Nsome attacks where an attacker may fiddle
Dialogue: 0,0:24:42.78,0:24:48.03,Default,,0000,0000,0000,,with the handshake. These were more or\Nless theoretic attacks. But these are also
Dialogue: 0,0:24:48.03,0:24:57.02,Default,,0000,0000,0000,,prevented in TLS 1.3. Yeah. So TLS has a\Nmore secure and a faster handshake. And if
Dialogue: 0,0:24:57.02,0:25:01.12,Default,,0000,0000,0000,,you want to have more details about this\Nhandshake there was a talk two years ago
Dialogue: 0,0:25:01.12,0:25:06.41,Default,,0000,0000,0000,,at this congress, which goes into this in\Nmuch more detail. So if this particularly
Dialogue: 0,0:25:06.41,0:25:10.14,Default,,0000,0000,0000,,interests you you should watch that talk.\NI've put a link here and I will put the
Dialogue: 0,0:25:10.14,0:25:19.87,Default,,0000,0000,0000,,slides online. There's also something\Ncalled the zero-roundtrip-handshake. And
Dialogue: 0,0:25:19.87,0:25:26.36,Default,,0000,0000,0000,,this is even faster. We can send data\Nright away. Now, how can we do that? This
Dialogue: 0,0:25:26.36,0:25:30.74,Default,,0000,0000,0000,,is kind of cheating because what we need\Nhere is we need to have a previous
Dialogue: 0,0:25:30.74,0:25:35.45,Default,,0000,0000,0000,,connection. And then we have a key from a\Nprevious connection, can create a new key
Dialogue: 0,0:25:35.45,0:25:42.04,Default,,0000,0000,0000,,from that and use that to send data right\Naway. So yeah, we need a so-called
Dialogue: 0,0:25:42.04,0:25:47.25,Default,,0000,0000,0000,,preshared-key which we have from previous\Nconnection and then we can send data
Dialogue: 0,0:25:47.25,0:25:58.45,Default,,0000,0000,0000,,without any roundtrips. So, even more\Nspeed. That's nice, right. But this 0-RTT-
Dialogue: 0,0:25:58.45,0:26:04.74,Default,,0000,0000,0000,,mode does not come for free. There is a\Nproblem here with so-called replay-
Dialogue: 0,0:26:04.74,0:26:11.30,Default,,0000,0000,0000,,attacks, which means an attacker could\Nrecord the data that we're sending and
Dialogue: 0,0:26:11.30,0:26:16.65,Default,,0000,0000,0000,,then send it again. And the server may\Nthink: Okay, now this request came twice.
Dialogue: 0,0:26:16.65,0:26:24.48,Default,,0000,0000,0000,,So I'm doing twice what this request was\Nsupposed to do. So there are some caveats
Dialogue: 0,0:26:24.48,0:26:29.45,Default,,0000,0000,0000,,with 0-RTT and the standard says you\Nshould only use if it's safe. It says
Dialogue: 0,0:26:29.45,0:26:36.71,Default,,0000,0000,0000,,something like you should only use it if\Nyou have a profile how to use it safely.
Dialogue: 0,0:26:36.71,0:26:43.62,Default,,0000,0000,0000,,Now what does that mean? There, let's look\Nat https, the protocol we're using
Dialogue: 0,0:26:43.62,0:26:49.28,Default,,0000,0000,0000,,usually. If you look into the HTTP-\Nstandard it says something that a GET-
Dialogue: 0,0:26:49.28,0:26:55.47,Default,,0000,0000,0000,,request has to be idempotent and a POST-\Nrequest does not have to be idempotent.
Dialogue: 0,0:26:55.47,0:26:59.78,Default,,0000,0000,0000,,Now what does that mean? It more or less\Nmeans if you send a request twice it
Dialogue: 0,0:26:59.78,0:27:07.46,Default,,0000,0000,0000,,shouldn't do anything different from just\Nsending it once. So in theory we could say
Dialogue: 0,0:27:07.46,0:27:13.18,Default,,0000,0000,0000,,yes a GET-requests are idempotent - that\Nmeans they are safe for zero-roundtrip-
Dialogue: 0,0:27:13.18,0:27:23.23,Default,,0000,0000,0000,,connections. The question is, "do web-\Ndevelopers" ... Sorry.
Dialogue: 0,0:27:23.23,0:27:30.84,Default,,0000,0000,0000,,{\i1}applause{\i0}\NYou can do a little experiment: If you
Dialogue: 0,0:27:30.84,0:27:34.97,Default,,0000,0000,0000,,meet someone who is a web developer, ask\Nthem if they know what idempotent means,
Dialogue: 0,0:27:34.97,0:27:42.91,Default,,0000,0000,0000,,and when they can use idempotent requests\Nand when they cannot. So, in an ideal
Dialogue: 0,0:27:42.91,0:27:47.75,Default,,0000,0000,0000,,situation where web-developers do know\Nthat, we can use 0-RTT safely with TLS
Dialogue: 0,0:27:47.75,0:27:57.20,Default,,0000,0000,0000,,1.3. 0-RTT also does not have a strong\Nforward secrecy as a normal handshake. So,
Dialogue: 0,0:27:57.20,0:28:02.09,Default,,0000,0000,0000,,there's kind of a tradeoff here, because\Nthis pre-shared key is encrypted with a
Dialogue: 0,0:28:02.09,0:28:06.30,Default,,0000,0000,0000,,key on the server and if that key gets\Ncompromised that may compromise our
Dialogue: 0,0:28:06.30,0:28:14.74,Default,,0000,0000,0000,,connection even if the key is only leaked\Nlater on. So, this looks a bit problematic
Dialogue: 0,0:28:14.74,0:28:19.90,Default,,0000,0000,0000,,and many speculate that the future attacks\Nwe'll see on TLS 1.3, that at least some
Dialogue: 0,0:28:19.90,0:28:24.47,Default,,0000,0000,0000,,of them will focus on this 0-RTT mode,\Nbecause it looks like one of the more
Dialogue: 0,0:28:24.47,0:28:29.06,Default,,0000,0000,0000,,fragile parts of the protocol. But it\Ngives us more speed., so people wanted to
Dialogue: 0,0:28:29.06,0:28:37.34,Default,,0000,0000,0000,,have it. Maybe the good news is, this is\Nentirely optional; we don't have to use
Dialogue: 0,0:28:37.34,0:28:42.89,Default,,0000,0000,0000,,it; and if we think this looks too\Nproblematic, we can switch it off. So, if
Dialogue: 0,0:28:42.89,0:28:46.88,Default,,0000,0000,0000,,it turns out that there are too many\Nattacks involving 0-RTT mode, we could
Dialogue: 0,0:28:46.88,0:28:51.56,Default,,0000,0000,0000,,disable it again and use it without it. It\Nwill still be faster, but not as fast as
Dialogue: 0,0:28:51.56,0:29:02.71,Default,,0000,0000,0000,,it could be with this. Okay. Deployment:\NNow, if we have this nice new protocol, we
Dialogue: 0,0:29:02.71,0:29:07.18,Default,,0000,0000,0000,,not only have to make sure it's secure and\Nfast and everything, but we also have to
Dialogue: 0,0:29:07.18,0:29:16.43,Default,,0000,0000,0000,,deploy it. And we have to deploy it on the\Ninternet - on the real internet - like the
Dialogue: 0,0:29:16.43,0:29:19.53,Default,,0000,0000,0000,,one we have out there, not some\Ntheoretical internet where there are no
Dialogue: 0,0:29:19.53,0:29:24.00,Default,,0000,0000,0000,,bugs and everyone knows how to implement\Nprotocols, but the real internet with lots
Dialogue: 0,0:29:24.00,0:29:32.38,Default,,0000,0000,0000,,of IoT devices and enterprise firewalls\Nand all these kinds of things. And now I
Dialogue: 0,0:29:32.38,0:29:40.66,Default,,0000,0000,0000,,want to get back to this version number.\NThis may sound like a trivial thing, but
Dialogue: 0,0:29:40.66,0:29:49.81,Default,,0000,0000,0000,,TLS 1.3 has a new version number for the\Nprotocol version. Here's a Wireshark dump
Dialogue: 0,0:29:49.81,0:29:55.79,Default,,0000,0000,0000,,from a TLS 1.3 handshake. And if you're\Ntrying to look for the version number, you
Dialogue: 0,0:29:55.79,0:30:02.12,Default,,0000,0000,0000,,will find multiple version numbers. And in\Ncase you cannot see it, I have made it a
Dialogue: 0,0:30:02.12,0:30:13.55,Default,,0000,0000,0000,,bit larger. So at the top you see\N"Version: TLS 1.0", encoded as 0x0301.
Dialogue: 0,0:30:13.55,0:30:20.15,Default,,0000,0000,0000,,Okay. That looks strange. Then, a few\Nlines later, you have "Version TLS: 1.2",
Dialogue: 0,0:30:20.15,0:30:27.84,Default,,0000,0000,0000,,0x0303. But we thought this was TLS 1.3...\NI mean it says here at the top but somehow
Dialogue: 0,0:30:27.84,0:30:34.00,Default,,0000,0000,0000,,there are these other versions. And then\Nif you scroll further down, you will see
Dialogue: 0,0:30:34.00,0:30:40.12,Default,,0000,0000,0000,,"Extension: supported_versions". And then\Nhere it lists TLS 1.3, which is encoded as
Dialogue: 0,0:30:40.12,0:30:47.48,Default,,0000,0000,0000,,0x0304. So, what's going on here? This\Nlooks strange. So, the first thing to
Dialogue: 0,0:30:47.48,0:30:51.89,Default,,0000,0000,0000,,realize is why do we encode these versions\Nin such a strange way; why are we not
Dialogue: 0,0:30:51.89,0:31:01.34,Default,,0000,0000,0000,,using 0x0100 for TLS 1.0? It's TLS 1.0\Ncame after SSL version 3, which kind of
Dialogue: 0,0:31:01.34,0:31:08.68,Default,,0000,0000,0000,,makes it version 3.1; and that's how we\Nencode it. TLS 1.0 is really just SSL
Dialogue: 0,0:31:08.68,0:31:17.96,Default,,0000,0000,0000,,version 3.1, TLS 1.1 is SSL version 3.2\Nand so on and for TLS 1.3, it's
Dialogue: 0,0:31:17.96,0:31:26.26,Default,,0000,0000,0000,,complicated. So, the very first version\Nyou saw earlier in this Wireshark dump was
Dialogue: 0,0:31:26.26,0:31:31.33,Default,,0000,0000,0000,,the so-called record layer and this is\Nkind of a protocol inside the TLS protocol
Dialogue: 0,0:31:31.33,0:31:36.64,Default,,0000,0000,0000,,which has its own version number, which is\Ntotally meaningless but it's just there.
Dialogue: 0,0:31:36.64,0:31:41.23,Default,,0000,0000,0000,,And it turned out, for compatibility\Nreasons, it's best to just let this on the
Dialogue: 0,0:31:41.23,0:31:46.38,Default,,0000,0000,0000,,version of TLS 1.0 and then, we have the\Nleast problems. And this is kind of...
Dialogue: 0,0:31:46.38,0:31:55.29,Default,,0000,0000,0000,,this record layer protocol is kind of the\Nencoding of the TLS packages. Now, if we
Dialogue: 0,0:31:55.29,0:32:00.30,Default,,0000,0000,0000,,have a new TLS version, we cannot just\Ntell everyone "tomorrow we will use TLS
Dialogue: 0,0:32:00.30,0:32:05.61,Default,,0000,0000,0000,,1.3" and everyone has to update, because\Nwe know many people won't. And so, we
Dialogue: 0,0:32:05.61,0:32:09.86,Default,,0000,0000,0000,,somehow need to be able to deploy this new\Nversion and still be compatible with
Dialogue: 0,0:32:09.86,0:32:19.84,Default,,0000,0000,0000,,devices that only speak the old version.\NSo, let's assume we have a client that
Dialogue: 0,0:32:19.84,0:32:27.51,Default,,0000,0000,0000,,supports TLS 1.2, and we have a server\Nthat only supports TLS 1.0. How does that
Dialogue: 0,0:32:27.51,0:32:34.92,Default,,0000,0000,0000,,work? That's an extremely complicated\Nmechanism here. So, the client connects
Dialogue: 0,0:32:34.92,0:32:44.27,Default,,0000,0000,0000,,and says "Hello. I speak TLS 1.2". Server\Nsays "Okay, I don't know TLS 1.2, but
Dialogue: 0,0:32:44.27,0:32:49.96,Default,,0000,0000,0000,,what's the highest version I support?"\NIt's TLS 1.0, so he sents that back. And
Dialogue: 0,0:32:49.96,0:32:55.72,Default,,0000,0000,0000,,then, they can speak TLS 1.0 and - in case\Nthe client still supports that - and we
Dialogue: 0,0:32:55.72,0:33:06.29,Default,,0000,0000,0000,,have a connection. This is very simple. I\Nwould think so. So, to illustrate how you
Dialogue: 0,0:33:06.29,0:33:11.32,Default,,0000,0000,0000,,would program something like that, you\Nwould say "Yeah, if client_max_version is
Dialogue: 0,0:33:11.32,0:33:16.48,Default,,0000,0000,0000,,smaller than than server_max_version, then\Nwe use the client_max_version. Otherwise,
Dialogue: 0,0:33:16.48,0:33:23.60,Default,,0000,0000,0000,,we use the server_max_version. So, you\Nwould think that there's no way anyone
Dialogue: 0,0:33:23.60,0:33:31.82,Default,,0000,0000,0000,,could possibly not get that right, right?\NI mean, it's very simple. But I was saying
Dialogue: 0,0:33:31.82,0:33:36.36,Default,,0000,0000,0000,,earlier, we were talking about the real\Ninternet. So... And on the real internet,
Dialogue: 0,0:33:36.36,0:33:41.36,Default,,0000,0000,0000,,we have enterprise products. In case you\Ndon't know that, an enterprise product is
Dialogue: 0,0:33:41.36,0:33:44.16,Default,,0000,0000,0000,,something that's very expensive and it's\Nbuggy.
Dialogue: 0,0:33:44.16,0:33:55.13,Default,,0000,0000,0000,,{\i1}Laughter{\i0}{\i1}Applause{\i0}\Nhanno: So, yeah. We will have web pages
Dialogue: 0,0:33:55.13,0:34:00.66,Default,,0000,0000,0000,,that run with firewalls from Cisco or we\Nwill have people using IBM Domino web
Dialogue: 0,0:34:00.66,0:34:06.59,Default,,0000,0000,0000,,server and all these kinds of things. And\Nthis is the TLS version negotiation in the
Dialogue: 0,0:34:06.59,0:34:13.91,Default,,0000,0000,0000,,enterprise edition. So a client says "Yeah\NI want to connect with TLS 1.2" and the
Dialogue: 0,0:34:13.91,0:34:18.52,Default,,0000,0000,0000,,server says "Oh I don't support this this\Nvery new version. It's from 2008. I mean
Dialogue: 0,0:34:18.52,0:34:29.03,Default,,0000,0000,0000,,that's 10 years in Enterprise years.\NThat's very long." So the server just
Dialogue: 0,0:34:29.03,0:34:33.55,Default,,0000,0000,0000,,sends an error if the client connects with\Nthe TLS version that it doesn't know. It
Dialogue: 0,0:34:33.55,0:34:38.83,Default,,0000,0000,0000,,doesn't implement this version negotiation\Ncorrectly. And this is called version
Dialogue: 0,0:34:38.83,0:34:47.14,Default,,0000,0000,0000,,intolerance. This has happened every time\Nthere was a new TLS version. Every time we
Dialogue: 0,0:34:47.14,0:34:51.95,Default,,0000,0000,0000,,had devices that had this problem. If we\Ntried to connect with the new TLS version
Dialogue: 0,0:34:51.95,0:34:54.83,Default,,0000,0000,0000,,they would just fail. They would send an\Nerror or they would just cut the
Dialogue: 0,0:34:54.83,0:35:03.46,Default,,0000,0000,0000,,connection or have a timeout or crash. So\Nbrowsers needed to handle this somehow
Dialogue: 0,0:35:03.46,0:35:07.77,Default,,0000,0000,0000,,because the problem here is, when a\Nbrowser introduces new TLS version and
Dialogue: 0,0:35:07.77,0:35:11.94,Default,,0000,0000,0000,,everything breaks, then users will blame\Nthe browser and then they will say "Yeah I
Dialogue: 0,0:35:11.94,0:35:15.54,Default,,0000,0000,0000,,will no longer use this browser, I'll now\Nswitch back to Internet Explorer" or
Dialogue: 0,0:35:15.54,0:35:23.89,Default,,0000,0000,0000,,something like that. So browsers needed to\Nhandle this somehow. What the browsers did
Dialogue: 0,0:35:23.89,0:35:30.05,Default,,0000,0000,0000,,was "Okay, we try it with the latest TLS\Nversion we support. And if we get an error
Dialogue: 0,0:35:30.05,0:35:35.34,Default,,0000,0000,0000,,we try it again with one version lower.\NAnd again one version lower and eventually
Dialogue: 0,0:35:35.34,0:35:41.40,Default,,0000,0000,0000,,we may succeed to connect." So here we\Nhave a browser and we have an enterprise
Dialogue: 0,0:35:41.40,0:35:49.97,Default,,0000,0000,0000,,server that supports TLS 1.0 and we will\Neventually get a connection. Do you
Dialogue: 0,0:35:49.97,0:35:56.04,Default,,0000,0000,0000,,remember POODLE I mentioned earlier? There\Nwas this padding oracle in SSLv3, which
Dialogue: 0,0:35:56.04,0:36:07.14,Default,,0000,0000,0000,,was discovered in 2014. You may wonder\NSSLv3 which is from 1996, that's really
Dialogue: 0,0:36:07.14,0:36:14.89,Default,,0000,0000,0000,,old. Who uses that in 2014? It was\Ndeprecated for 16 years. I mean who uses
Dialogue: 0,0:36:14.89,0:36:24.39,Default,,0000,0000,0000,,that? Windows Phone 7 used it. On this\NNokia phones they also never got an
Dialogue: 0,0:36:24.39,0:36:35.63,Default,,0000,0000,0000,,update. Normal browsers and servers at\Nleast used TLS 1.0. They maybe didn't use
Dialogue: 0,0:36:35.63,0:36:44.84,Default,,0000,0000,0000,,TLS 1.2, but they used TLS 1.0. But we\Nhave these browsers that are trying to
Dialogue: 0,0:36:44.84,0:36:51.40,Default,,0000,0000,0000,,reconnect if there's an error. And so what\Nan attacker could do is that the attacker
Dialogue: 0,0:36:51.40,0:36:58.47,Default,,0000,0000,0000,,wants to exploit SSLv3. So he just blocks\Nall connections with the newer TLS version
Dialogue: 0,0:36:58.47,0:37:05.66,Default,,0000,0000,0000,,and therefore forces the client to go into\NSSLv3. And then he can exploit this attack
Dialogue: 0,0:37:05.66,0:37:18.82,Default,,0000,0000,0000,,that only works on SSLv3. These downgrades\Nare causing security issues. What do we do
Dialogue: 0,0:37:18.82,0:37:24.93,Default,,0000,0000,0000,,now? We could add another work workaround.\NThere was a standard called SCSV which
Dialogue: 0,0:37:24.93,0:37:31.79,Default,,0000,0000,0000,,basically gives the server a way to tell\Nthe client that it's not broken. It says
Dialogue: 0,0:37:31.79,0:37:40.47,Default,,0000,0000,0000,,"hey, I have this kind of special cipher\Nsuite" which tells the client "hey, if you
Dialogue: 0,0:37:40.47,0:37:46.01,Default,,0000,0000,0000,,did these strange downgrades here, please\Ndon't do that. I'm a well behaving
Dialogue: 0,0:37:46.01,0:37:51.87,Default,,0000,0000,0000,,server." So we had a workaround for broken\Nservers and then we needed another
Dialogue: 0,0:37:51.87,0:37:57.02,Default,,0000,0000,0000,,workaround for the security issues caused\Nby those workarounds. But at some points
Dialogue: 0,0:37:57.02,0:38:02.08,Default,,0000,0000,0000,,even enterprise servers mostly had fixed\Nthis version intolerance issues and
Dialogue: 0,0:38:02.08,0:38:10.10,Default,,0000,0000,0000,,browsers stopped doing these downgrades.\NAttacks like POODLE no longer worked.
Dialogue: 0,0:38:10.10,0:38:15.85,Default,,0000,0000,0000,,However I just said they fixed it. No of\Ncourse they have not fixed it. I mean they
Dialogue: 0,0:38:15.85,0:38:21.31,Default,,0000,0000,0000,,fixed it for TLS 1.2. But of course they\Ndid not fix it for future TLS versions
Dialogue: 0,0:38:21.31,0:38:28.65,Default,,0000,0000,0000,,because they were not around yet. This TLS\N1.3, we would get version intolerance
Dialogue: 0,0:38:28.65,0:38:33.13,Default,,0000,0000,0000,,again and breaking servers and would have\Nto introduce downgrades again and all the
Dialogue: 0,0:38:33.13,0:38:42.11,Default,,0000,0000,0000,,nice security would not be very helpful.\NThe TLS working group realized that and
Dialogue: 0,0:38:42.11,0:38:48.22,Default,,0000,0000,0000,,redesigned the handshake. It was\Nredesigned in a way that the old version
Dialogue: 0,0:38:48.22,0:38:53.39,Default,,0000,0000,0000,,fields still said that we are connecting\Nwith TLS 1.2 and then we introduce an
Dialogue: 0,0:38:53.39,0:39:00.20,Default,,0000,0000,0000,,extension, supported_versions, which\Nsignals the support for all the TLS
Dialogue: 0,0:39:00.20,0:39:04.83,Default,,0000,0000,0000,,versions we can speak and which signals\Nsupport for TLS 1.3 and possibly for
Dialogue: 0,0:39:04.83,0:39:12.72,Default,,0000,0000,0000,,future versions. Now at this point you may\Nwonder if we'll have version intolerance
Dialogue: 0,0:39:12.72,0:39:18.43,Default,,0000,0000,0000,,with this new extension, once TLS 1.4 gets\Nout because the server may be implemented
Dialogue: 0,0:39:18.43,0:39:23.02,Default,,0000,0000,0000,,that it sends an error if it sees an\Nunknown version in this new version
Dialogue: 0,0:39:23.02,0:39:31.62,Default,,0000,0000,0000,,extension. David Benjamin from Google\Nthought about this and said "Yeah we have
Dialogue: 0,0:39:31.62,0:39:36.71,Default,,0000,0000,0000,,to do something about that. We have to\Nimprove the future compatibility for
Dialogue: 0,0:39:36.71,0:39:44.84,Default,,0000,0000,0000,,future TLS versions." And he invented this\NGREASE mechanism. The idea here is, a
Dialogue: 0,0:39:44.84,0:39:50.07,Default,,0000,0000,0000,,server should just ignore unknown versions\Nin this extension. He gets a list of TLS
Dialogue: 0,0:39:50.07,0:39:53.90,Default,,0000,0000,0000,,versions and if there's one in there that\Nhe doesn't know about, he should just
Dialogue: 0,0:39:53.90,0:40:00.86,Default,,0000,0000,0000,,ignore it and then connect with one of the\Nversions he knows about. So we could kind
Dialogue: 0,0:40:00.86,0:40:07.43,Default,,0000,0000,0000,,of try to train servers to actually do\Nthat. And the idea here is we're just
Dialogue: 0,0:40:07.43,0:40:12.98,Default,,0000,0000,0000,,sending random bogus TLS versions that are\Nreserved values that will never be used
Dialogue: 0,0:40:12.98,0:40:17.98,Default,,0000,0000,0000,,for a real TLS version. But we can just\Nrandomly add them to this extension in
Dialogue: 0,0:40:17.98,0:40:22.47,Default,,0000,0000,0000,,order to make sure that if a server\Nimplements this incorrectly, they will
Dialogue: 0,0:40:22.47,0:40:27.05,Default,,0000,0000,0000,,hopefully recognize that early because\Nthere will be connection failures with
Dialogue: 0,0:40:27.05,0:40:40.87,Default,,0000,0000,0000,,normal browsers. The hope here is if\Nenterprise vendors will implement a broken
Dialogue: 0,0:40:40.87,0:40:45.09,Default,,0000,0000,0000,,version negotiation, they will hopefully\Nnotice that before they ship the product
Dialogue: 0,0:40:45.09,0:40:51.79,Default,,0000,0000,0000,,and then it can no longer be updated\Nbecause that's how the Internet works. So
Dialogue: 0,0:40:51.79,0:40:55.84,Default,,0000,0000,0000,,we have this new version negotiation\Nmechanism we no longer need these
Dialogue: 0,0:40:55.84,0:41:00.23,Default,,0000,0000,0000,,downgrades and we have this GREASE\Nmechanism to make it future proof. So now
Dialogue: 0,0:41:00.23,0:41:17.48,Default,,0000,0000,0000,,we can ship TLS 1.3, right? Then there was\Nthis middle box issue. Oh sorry, that's a
Dialogue: 0,0:41:17.48,0:41:25.67,Default,,0000,0000,0000,,wrong year. It must be 2016, sorry. In\N2016, in summer, TLS 1.3 was almost
Dialogue: 0,0:41:25.67,0:41:32.94,Default,,0000,0000,0000,,finished. But then it took almost another\Nyear till it got out. Oh sorry, I mixed up
Dialogue: 0,0:41:32.94,0:41:41.42,Default,,0000,0000,0000,,the years. It's correct. In 2017, when TLS\N1.3 was almost finished, but it took until
Dialogue: 0,0:41:41.42,0:41:48.53,Default,,0000,0000,0000,,2018 until it was actually finished. The\Nreason for that was that when browser
Dialogue: 0,0:41:48.53,0:41:54.66,Default,,0000,0000,0000,,vendors implemented a draft version of TLS\N1.3, they noticed a lot of connection
Dialogue: 0,0:41:54.66,0:42:00.78,Default,,0000,0000,0000,,failures. And the reason for these\Nconnection failures turned out, were
Dialogue: 0,0:42:00.78,0:42:05.16,Default,,0000,0000,0000,,devices that were trying to analyze the\Ntraffic and trying to be smart. And they
Dialogue: 0,0:42:05.16,0:42:09.01,Default,,0000,0000,0000,,thought "OK this is something that looks\Nvery strange. It doesn't look like a TLS
Dialogue: 0,0:42:09.01,0:42:16.04,Default,,0000,0000,0000,,package how we're used to it. So let's\Njust drop it, yeah?" So "Yeah, this is a
Dialogue: 0,0:42:16.04,0:42:22.89,Default,,0000,0000,0000,,strange TLS package, I don't know what\Nto do with this, I'll drop it." These were
Dialogue: 0,0:42:22.89,0:42:26.48,Default,,0000,0000,0000,,largely passive middle boxes. So we're not\Ntalking about things like man in the
Dialogue: 0,0:42:26.48,0:42:30.07,Default,,0000,0000,0000,,middle devices that are intercepting a TLS\Nconnection but just something like a
Dialogue: 0,0:42:30.07,0:42:33.86,Default,,0000,0000,0000,,router, where you would expect it just\Nforwards traffic. But it tries to be
Dialogue: 0,0:42:33.86,0:42:38.69,Default,,0000,0000,0000,,smart, it tries to do advanced security\Nenterprise. I don't know. And they were
Dialogue: 0,0:42:38.69,0:42:46.94,Default,,0000,0000,0000,,dropping traffic that looked like TLS 1.3\NThen the browser vendors proposed some
Dialogue: 0,0:42:46.94,0:42:56.91,Default,,0000,0000,0000,,changes to TLS 1.3 so it looks more like\NTLS 1.2. The main thing was, they
Dialogue: 0,0:42:56.91,0:43:03.46,Default,,0000,0000,0000,,introduced some bogus messages from TLS\N1.2 that were supposed to be ignored. So
Dialogue: 0,0:43:03.46,0:43:08.49,Default,,0000,0000,0000,,one such message is the so-called\NChangeCipherSpec message in TLS 1.2, which
Dialogue: 0,0:43:08.49,0:43:15.72,Default,,0000,0000,0000,,originally didn't exist in 1.3 due to this\Nnew handshake design. This message in 1.2,
Dialogue: 0,0:43:15.72,0:43:22.98,Default,,0000,0000,0000,,it signals that everything from now on is\Nencrypted. The idea was "okay, if we sent
Dialogue: 0,0:43:22.98,0:43:28.36,Default,,0000,0000,0000,,a bogus ChangeCipherSpec message early in\Nthe handshake, then maybe this would
Dialogue: 0,0:43:28.36,0:43:32.56,Default,,0000,0000,0000,,confuse those devices, thinking everything\Nafter that is encrypted and they cannot
Dialogue: 0,0:43:32.56,0:43:38.35,Default,,0000,0000,0000,,analyze it." And it turned out this\Nworked. A lot of this reduced the
Dialogue: 0,0:43:38.35,0:43:45.09,Default,,0000,0000,0000,,connection failures a lot. There are a few\Nother things. And then eventually the
Dialogue: 0,0:43:45.09,0:43:52.34,Default,,0000,0000,0000,,failure rates got low enough that browsers\Nthought "Okay, now we can deploy this."
Dialogue: 0,0:43:52.34,0:44:00.31,Default,,0000,0000,0000,,There were a few more issues. This is a\NPixma printer from Canon. These things
Dialogue: 0,0:44:00.31,0:44:06.42,Default,,0000,0000,0000,,have an HTTPS server. They have network\Nsupport. And we have to talk about these
Dialogue: 0,0:44:06.42,0:44:16.39,Default,,0000,0000,0000,,people here. If you remember the Snowden\Nrelations, one of the things that got
Dialogue: 0,0:44:16.39,0:44:20.18,Default,,0000,0000,0000,,highlighted there was that there's a\Nrandom number generator called Dual EC
Dialogue: 0,0:44:20.18,0:44:25.71,Default,,0000,0000,0000,,DRBG. And that has a backdoor and\Nbasically these days everyone believes
Dialogue: 0,0:44:25.71,0:44:30.29,Default,,0000,0000,0000,,this is a backdoor by the NSA and they\Nhave some secret keys so they can predict
Dialogue: 0,0:44:30.29,0:44:39.66,Default,,0000,0000,0000,,what random values this RNG will output.\NAlso what was in the Snowden documents was
Dialogue: 0,0:44:39.66,0:44:44.58,Default,,0000,0000,0000,,that at some point the NSA offered 10\Nmillion dollars to RSA security, so they
Dialogue: 0,0:44:44.58,0:44:55.51,Default,,0000,0000,0000,,implement this RNG. Then there was a\Nproposal, a draft, for a TLS extension,
Dialogue: 0,0:44:55.51,0:45:02.98,Default,,0000,0000,0000,,called Extended Random, that adds some\Nextra random numbers to the TLS handshake.
Dialogue: 0,0:45:02.98,0:45:08.19,Default,,0000,0000,0000,,Why? It wasn't really clear like it was\Njust "Yeah we can do this." It was just a
Dialogue: 0,0:45:08.19,0:45:12.30,Default,,0000,0000,0000,,proposal. I mean everyone can write a\Nproposal for a new extension, it was never
Dialogue: 0,0:45:12.30,0:45:20.61,Default,,0000,0000,0000,,finalized, but it was out there. And in\N2014, a research team looked closer at
Dialogue: 0,0:45:20.61,0:45:29.42,Default,,0000,0000,0000,,this Dual EC RNG and figured out that if\Nyou use this ER extension then it's much
Dialogue: 0,0:45:29.42,0:45:39.29,Default,,0000,0000,0000,,easier to exploit this backdoor in this\NRNG. And coincidentally RSA's TLS library,
Dialogue: 0,0:45:39.29,0:45:45.33,Default,,0000,0000,0000,,BSAFE, also contains support for that\Nextension. But it was switched off. They
Dialogue: 0,0:45:45.33,0:45:48.81,Default,,0000,0000,0000,,didn't find any implementations that\Nactually used it. So it was thought of
Dialogue: 0,0:45:48.81,0:45:53.54,Default,,0000,0000,0000,,"okay, this was no big deal, all right".\NBut actually it seems these these Canon
Dialogue: 0,0:45:53.54,0:46:00.73,Default,,0000,0000,0000,,printers, they had enabled this extension.\NThey use this RSA BSAFE library and
Dialogue: 0,0:46:00.73,0:46:08.04,Default,,0000,0000,0000,,enabled this ER extension, which was only\Na draft. And so as ER was only a draft, it
Dialogue: 0,0:46:08.04,0:46:13.81,Default,,0000,0000,0000,,had no official extension number. So such\Na TLS extension has a number so that the
Dialogue: 0,0:46:13.81,0:46:19.09,Default,,0000,0000,0000,,server knows what kind of extension this\Nis. And for this implementation they just
Dialogue: 0,0:46:19.09,0:46:24.06,Default,,0000,0000,0000,,used the next available number. And it\Nturned out that this number collided with
Dialogue: 0,0:46:24.06,0:46:32.99,Default,,0000,0000,0000,,one of the mandatory extensions that TLS\N1.3 introduced. So these these Canon
Dialogue: 0,0:46:32.99,0:46:36.32,Default,,0000,0000,0000,,printers could not interpret that new\Nextension. They thought this is this
Dialogue: 0,0:46:36.32,0:46:45.29,Default,,0000,0000,0000,,Extended Random and it didn't make any\Nsense, and so you had connection failures.
Dialogue: 0,0:46:45.29,0:46:50.05,Default,,0000,0000,0000,,In the TLS protocol they just gave this\Nextension a new number and then this no
Dialogue: 0,0:46:50.05,0:46:58.01,Default,,0000,0000,0000,,longer happened. There were many more such\Nissues and they continue to show up. For
Dialogue: 0,0:46:58.01,0:47:02.86,Default,,0000,0000,0000,,example recently, Java, which is like also\Nvery popular in enterprise environments,
Dialogue: 0,0:47:02.86,0:47:06.91,Default,,0000,0000,0000,,it now ships with TLS 1.3 support but it\Ndoesn't really work. So you have
Dialogue: 0,0:47:06.91,0:47:16.58,Default,,0000,0000,0000,,connection failures there. Now with all\Nthese deployment issues, what about future
Dialogue: 0,0:47:16.58,0:47:20.57,Default,,0000,0000,0000,,TLS versions? Will we have all that again?\NAnd we have this GREASE mechanism and it
Dialogue: 0,0:47:20.57,0:47:25.22,Default,,0000,0000,0000,,helps a bit like it prevents this version\Nintolerance issues but it doesn't prevent
Dialogue: 0,0:47:25.22,0:47:32.35,Default,,0000,0000,0000,,these more complicated middle box issues.\NThere was a proposal from David Benjamin
Dialogue: 0,0:47:32.35,0:47:36.10,Default,,0000,0000,0000,,from Google who said "Yeah, maybe we\Nshould just, every few months, like every
Dialogue: 0,0:47:36.10,0:47:40.99,Default,,0000,0000,0000,,two or three months, ship a new temporary\NTLS version which we will use for three
Dialogue: 0,0:47:40.99,0:47:47.77,Default,,0000,0000,0000,,months and then we will deprecate it again\Nto just constantly change the protocol so
Dialogue: 0,0:47:47.77,0:47:51.15,Default,,0000,0000,0000,,that the Internet gets used to the fact\Nthat new protocols get introduced."
Dialogue: 0,0:47:51.15,0:47:56.92,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\NMy prediction here is that these
Dialogue: 0,0:47:56.92,0:48:01.03,Default,,0000,0000,0000,,deployment issues are going to get worse.\NI mean, we know now that they exist and we
Dialogue: 0,0:48:01.03,0:48:08.23,Default,,0000,0000,0000,,kind of have some ideas how to prevent\Nthem, but if you go to enterprise security
Dialogue: 0,0:48:08.23,0:48:13.86,Default,,0000,0000,0000,,conferences, you will know that the latest\Ntrend in enterprise security is this thing
Dialogue: 0,0:48:13.86,0:48:19.41,Default,,0000,0000,0000,,called artificial intelligence: We use\Nmachine learning and fancy algorithms to
Dialogue: 0,0:48:19.41,0:48:27.81,Default,,0000,0000,0000,,detect bad stuff. And that worries me. And\Nhere's a blog post from Cisco, where they
Dialogue: 0,0:48:27.81,0:48:32.57,Default,,0000,0000,0000,,want to use machine learning to detect bad\NTLS traffic, because they see all this
Dialogue: 0,0:48:32.57,0:48:37.22,Default,,0000,0000,0000,,traffic is encrypted and we can no longer\Nanalyze it, we don't know if malware in
Dialogue: 0,0:48:37.22,0:48:42.77,Default,,0000,0000,0000,,there, so let's use some machine learning;\Nit will detect bad traffic. So, what I'm
Dialogue: 0,0:48:42.77,0:48:48.10,Default,,0000,0000,0000,,very worried that will happen here is that\Nthe next generation of TLS deployment
Dialogue: 0,0:48:48.10,0:48:53.32,Default,,0000,0000,0000,,issues will be AI-supported TLS\Nintolerance issues and it may be much
Dialogue: 0,0:48:53.32,0:49:04.13,Default,,0000,0000,0000,,harder to fix and analyze. Speaking of\Nenterprise environments, one of the very
Dialogue: 0,0:49:04.13,0:49:11.69,Default,,0000,0000,0000,,early changes in TLS 1.3 was that it\Nremoved the RSA encryption handshake. One
Dialogue: 0,0:49:11.69,0:49:15.26,Default,,0000,0000,0000,,reason was that it doesn't have forward\Nsecrecy. The other was these, all these
Dialogue: 0,0:49:15.26,0:49:23.15,Default,,0000,0000,0000,,Bleichenbacher attacks that I talked about\Nearlier. And then, there came an email to
Dialogue: 0,0:49:23.15,0:49:31.19,Default,,0000,0000,0000,,the TLS working group from the banking\Nindustry and I quote: "I recently learned
Dialogue: 0,0:49:31.19,0:49:34.72,Default,,0000,0000,0000,,of a proposed change that would affect\Nmany of my organization's member
Dialogue: 0,0:49:34.72,0:49:40.17,Default,,0000,0000,0000,,institutions: the deprecation of the RSA\Nkey exchange. Deprecation of the RSA key
Dialogue: 0,0:49:40.17,0:49:44.14,Default,,0000,0000,0000,,exchange in TLS 1.3 will cause significant\Nproblems for financial institutions,
Dialogue: 0,0:49:44.14,0:49:48.60,Default,,0000,0000,0000,,almost all of whom are running TLS\Ninternally and have significant, security-
Dialogue: 0,0:49:48.60,0:49:54.87,Default,,0000,0000,0000,,critical investments in out-of-band TLS\Ndecryption." What it basically means is,
Dialogue: 0,0:49:54.87,0:49:59.12,Default,,0000,0000,0000,,they are using TLS for some connection;\Nthey have some device in the middle that
Dialogue: 0,0:49:59.12,0:50:05.87,Default,,0000,0000,0000,,is decrypting the traffic and analyzing it\Nsomehow which - if they do it internally -
Dialogue: 0,0:50:05.87,0:50:11.79,Default,,0000,0000,0000,,it's okay, but this no longer works with\NTLS 1.3, because we always negotiate a new
Dialogue: 0,0:50:11.79,0:50:20.90,Default,,0000,0000,0000,,key for each connection and it's no longer\Npossible to have the static decryption.
Dialogue: 0,0:50:20.90,0:50:25.97,Default,,0000,0000,0000,,There was an answer from Kenny Patterson,\Nhe's a professor from London, he said: "My
Dialogue: 0,0:50:25.97,0:50:29.36,Default,,0000,0000,0000,,view concerning your request: no.\NRationale: We're trying to build a more
Dialogue: 0,0:50:29.36,0:50:37.47,Default,,0000,0000,0000,,secure internet."\N{\i1}Applause{\i0}
Dialogue: 0,0:50:37.47,0:50:41.24,Default,,0000,0000,0000,,"You're a bit late to the party. We're\Nmetaphorically speaking at the stage of
Dialogue: 0,0:50:41.24,0:50:46.05,Default,,0000,0000,0000,,emptying the ash trays and hunting for the\Nnot quite empty beer cans. More exactly,
Dialogue: 0,0:50:46.05,0:50:50.56,Default,,0000,0000,0000,,we are at draft 15 and RSA key transport\Ndisappeared from the spec about a dozen
Dialogue: 0,0:50:50.56,0:50:55.62,Default,,0000,0000,0000,,drafts ago. I know the banking industry is\Nusually a bit slow off the mark, but this
Dialogue: 0,0:50:55.62,0:51:00.70,Default,,0000,0000,0000,,takes the biscuit." Okay.\N{\i1}Laughter{\i0}
Dialogue: 0,0:51:00.70,0:51:07.90,Default,,0000,0000,0000,,There were several proposals then to add a\Nvisibility mode to TLS 1.3, which would in
Dialogue: 0,0:51:07.90,0:51:13.80,Default,,0000,0000,0000,,another way allow these connections that\Ncould be passively observed and decrypted,
Dialogue: 0,0:51:13.80,0:51:18.51,Default,,0000,0000,0000,,but they were all rejected and the general\Nopinion in the TLS working group was that
Dialogue: 0,0:51:18.51,0:51:23.98,Default,,0000,0000,0000,,the goal of monitoring traffic content is\Njust fundamentally not the goal of TLS.
Dialogue: 0,0:51:23.98,0:51:31.21,Default,,0000,0000,0000,,The goal of TLS is to have an encrypted\Nchannel that no one else can read. The
Dialogue: 0,0:51:31.21,0:51:37.90,Default,,0000,0000,0000,,industry eventually went to ETSI, which is\Nthe European technology standardization
Dialogue: 0,0:51:37.90,0:51:43.59,Default,,0000,0000,0000,,organization, and they recently published\Nsomething called Enterprise TLS...
Dialogue: 0,0:51:43.59,0:51:51.37,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\N...which modifies TLS 1.3 in a way that it
Dialogue: 0,0:51:51.37,0:51:57.88,Default,,0000,0000,0000,,would allow these decryptions. The IETF\Nprotested against that and primarily
Dialogue: 0,0:51:57.88,0:52:02.98,Default,,0000,0000,0000,,because of the... they used the name TLS,\Nbecause it sounds like this is some
Dialogue: 0,0:52:02.98,0:52:08.36,Default,,0000,0000,0000,,addition to TLS or something, and\Napparently ETSI has previously promised to
Dialogue: 0,0:52:08.36,0:52:14.34,Default,,0000,0000,0000,,them that they would not use the name TLS\Nand then they named it Enterprise TLS.
Dialogue: 0,0:52:14.34,0:52:23.95,Default,,0000,0000,0000,,Okay, but yeah... TLS 1.3 is finished. You\Ncan start using it. You should update your
Dialogue: 0,0:52:23.95,0:52:29.80,Default,,0000,0000,0000,,servers so that they use it. Your browser\Nprobably already supports it. So, in
Dialogue: 0,0:52:29.80,0:52:41.17,Default,,0000,0000,0000,,summary: TLS 1.3 deprecates many insecure\Nconstructions. It's faster and deploying
Dialogue: 0,0:52:41.17,0:52:47.89,Default,,0000,0000,0000,,new things on the internet is a mess. So,\Nyeah. That's it. And I think we have a few
Dialogue: 0,0:52:47.89,0:52:59.60,Default,,0000,0000,0000,,minutes for questions.\N{\i1}Applause{\i0}
Dialogue: 0,0:52:59.60,0:53:03.61,Default,,0000,0000,0000,,Herald: Alright, yeah. As Hanno mentioned, we\Nhave 6 minutes or so for questions. We
Dialogue: 0,0:53:03.61,0:53:07.75,Default,,0000,0000,0000,,have 5 microphones in the room. So, if you\Nwant to ask a question, hurry up to one of
Dialogue: 0,0:53:07.75,0:53:11.75,Default,,0000,0000,0000,,the microphones and please make sure to\Nask a short, concise question, so that we
Dialogue: 0,0:53:11.75,0:53:16.18,Default,,0000,0000,0000,,can get as many in as we can possibly can.\NMaybe, you just go ahead over there. Mic
Dialogue: 0,0:53:16.18,0:53:18.25,Default,,0000,0000,0000,,2.\NMic 2: Thank you very much for this
Dialogue: 0,0:53:18.25,0:53:23.92,Default,,0000,0000,0000,,interesting talk. Is there a way to\Nprevent the uses of this Enterprise TLS?
Dialogue: 0,0:53:23.92,0:53:27.49,Default,,0000,0000,0000,,Hanno: The question is if there is a way\Nto prevent the use of that Enterprise TLS.
Dialogue: 0,0:53:27.49,0:53:33.21,Default,,0000,0000,0000,,Yes, there is, because the basic idea is\Nthat they will use a static Diffie-Hellman
Dialogue: 0,0:53:33.21,0:53:38.35,Default,,0000,0000,0000,,key exchange and if you just connect twice\Nand see that they are using the same
Dialogue: 0,0:53:38.35,0:53:43.21,Default,,0000,0000,0000,,again, then you may reject that. Although\Nthe problem is, some servers may also use
Dialogue: 0,0:53:43.21,0:53:52.41,Default,,0000,0000,0000,,that for optimization. So, there are\Nlonger discussions on this question, so...
Dialogue: 0,0:53:52.41,0:53:57.49,Default,,0000,0000,0000,,I cannot fully answer it, but there more\Nor less... there are options.
Dialogue: 0,0:53:57.49,0:54:00.47,Default,,0000,0000,0000,,Herald: Alright. Before we go to the next\Nquestion, a quick request for all the
Dialogue: 0,0:54:00.47,0:54:05.02,Default,,0000,0000,0000,,people leaving the room: Please do so as\Nquietly as possible, so we can finish this
Dialogue: 0,0:54:05.02,0:54:10.61,Default,,0000,0000,0000,,Q&A in peace and don't have all this noise\Ngoing on. Mic 3, please.
Dialogue: 0,0:54:10.61,0:54:16.74,Default,,0000,0000,0000,,Mic 3: Hi. I was wondering about the\Nreplay attacks. Why didn't they implement
Dialogue: 0,0:54:16.74,0:54:21.86,Default,,0000,0000,0000,,something like sequence numbers into the\NTLS protocol?
Dialogue: 0,0:54:21.86,0:54:25.16,Default,,0000,0000,0000,,Hanno: Yeah. There is something like that\Nin there. The problem is, you sometimes
Dialogue: 0,0:54:25.16,0:54:30.27,Default,,0000,0000,0000,,have a situation where you have multiple\NTLS termination points - for example, if
Dialogue: 0,0:54:30.27,0:54:34.11,Default,,0000,0000,0000,,you have a CDN network that is\Ninternationally distributed - and you may
Dialogue: 0,0:54:34.11,0:54:40.45,Default,,0000,0000,0000,,not be able to keep state across all of\Nthem.
Dialogue: 0,0:54:40.45,0:54:44.39,Default,,0000,0000,0000,,Herald: Alright. Then, let's take a\Nquestion from our viewers in the internet.
Dialogue: 0,0:54:44.39,0:54:50.27,Default,,0000,0000,0000,,The signal angel, please.\NSignal angel: Alright. Binarystrike asks:
Dialogue: 0,0:54:50.27,0:54:55.33,Default,,0000,0000,0000,,"With regards to TLS 1.3 in the\Nenterprise, shouldn't we move away from
Dialogue: 0,0:54:55.33,0:55:00.74,Default,,0000,0000,0000,,perimeter interception devices to also\Nputting control on the end point, like we
Dialogue: 0,0:55:00.74,0:55:09.63,Default,,0000,0000,0000,,would have in a zero-trust environment?"\NHanno: So, in my opinion, yes. But, there
Dialogue: 0,0:55:09.63,0:55:14.73,Default,,0000,0000,0000,,are many people in the enterise security\Nindustry who think that this is not
Dialogue: 0,0:55:14.73,0:55:20.27,Default,,0000,0000,0000,,feasible. But, I mean, discussion about\Nnetwork design, that would be a whole
Dialogue: 0,0:55:20.27,0:55:24.87,Default,,0000,0000,0000,,other talk. Yeah.\NHerald: Alright. Then, let's take a
Dialogue: 0,0:55:24.87,0:55:29.75,Default,,0000,0000,0000,,question from mic 4.\NMic 4: Yeah. It's also related to the
Dialogue: 0,0:55:29.75,0:55:37.43,Default,,0000,0000,0000,,Enterprise TLS. The browser can connect to\Nan Enterprise TLS server without any
Dialogue: 0,0:55:37.43,0:55:41.20,Default,,0000,0000,0000,,problems?\NHanno: Yeah. So, it's built that it's
Dialogue: 0,0:55:41.20,0:55:46.59,Default,,0000,0000,0000,,compatible with the existing TLS protocol.\NMic 4: Okay, thanks.
Dialogue: 0,0:55:46.59,0:55:50.05,Default,,0000,0000,0000,,Hanno: And the reason of whether you can\Navoid that or not, that's really a more
Dialogue: 0,0:55:50.05,0:55:54.28,Default,,0000,0000,0000,,complicated discussion, that would kind of\Nbe a whole sub-talk, so I cannot answer
Dialogue: 0,0:55:54.28,0:55:58.83,Default,,0000,0000,0000,,this in a minute, but come to me later if\Nyou are interested in details.
Dialogue: 0,0:55:58.83,0:56:01.68,Default,,0000,0000,0000,,Herald: Alright. Then, let's take another\Nquestion from the interwebs.
Dialogue: 0,0:56:01.68,0:56:06.45,Default,,0000,0000,0000,,Signal Angel: We have one more question\Nfrom IRC: "Would you recommend
Dialogue: 0,0:56:06.45,0:56:14.75,Default,,0000,0000,0000,,inserting bogus values into handshakes to\Ntrain implementors?"
Dialogue: 0,0:56:14.75,0:56:18.71,Default,,0000,0000,0000,,Hanno: I mean that what I said what is\Ndone, that's actually what browsers are
Dialogue: 0,0:56:18.71,0:56:23.74,Default,,0000,0000,0000,,doing, and I think this is a good idea. I\Njust think that this covers only a small
Dialogue: 0,0:56:23.74,0:56:29.34,Default,,0000,0000,0000,,fraction of these deployment issues.\NHerald: Okay, we still have plenty of
Dialogue: 0,0:56:29.34,0:56:34.82,Default,,0000,0000,0000,,time, so let's go to mic 2 please.\NMic 2: Yeah, as you said, we have still a
Dialogue: 0,0:56:34.82,0:56:40.93,Default,,0000,0000,0000,,lot of dirty workarounds concerning TLS\N1.3 and all the implementatons in the
Dialogue: 0,0:56:40.93,0:56:51.79,Default,,0000,0000,0000,,browers and so on. Is there a way to make,\Nlike, a requirement for the TLS 1.3 or 1.4
Dialogue: 0,0:56:51.79,0:57:01.32,Default,,0000,0000,0000,,compliance to meet some compliance to the\Nstandard? So you have like a test you can
Dialogue: 0,0:57:01.32,0:57:05.95,Default,,0000,0000,0000,,perform, a self-test or something like\Nthat and if you pass that you are allowed
Dialogue: 0,0:57:05.95,0:57:16.44,Default,,0000,0000,0000,,to use the TLS 1.3 logo or 1.4 logo.\NHanno: You can do that in theory. The
Dialogue: 0,0:57:16.44,0:57:23.19,Default,,0000,0000,0000,,problem is you don't really want to have a\Ncertification regime that people like have
Dialogue: 0,0:57:23.19,0:57:28.86,Default,,0000,0000,0000,,to ask for a logo to be able to be allowed\Nto implement TLS. and I mean that's kind
Dialogue: 0,0:57:28.86,0:57:32.53,Default,,0000,0000,0000,,of one of the downsides of the open\Narchitecture of the Internet, right? We
Dialogue: 0,0:57:32.53,0:57:36.42,Default,,0000,0000,0000,,allow everyone to put devices on the\NInternet, so we kind of have to live with
Dialogue: 0,0:57:36.42,0:57:43.82,Default,,0000,0000,0000,,that. And there's no TLS police, so, we\Nkind of have no way of preventing people
Dialogue: 0,0:57:43.82,0:57:49.21,Default,,0000,0000,0000,,to use broken TLS implementations. And I\Nmean people won't care if they have a logo
Dialogue: 0,0:57:49.21,0:57:54.54,Default,,0000,0000,0000,,for it or not, right?\NHerald: Alright, let's go to mic 5 all the
Dialogue: 0,0:57:54.54,0:57:58.75,Default,,0000,0000,0000,,way in the back there.\NMic 5: Okay. I have a question about
Dialogue: 0,0:57:58.75,0:58:05.57,Default,,0000,0000,0000,,Shor's algorithm and TLS 1.3, because\Nsince quantum computing is getting very
Dialogue: 0,0:58:05.57,0:58:10.53,Default,,0000,0000,0000,,popular lately and there are a lot of\Nimprovements in the industries, so what's
Dialogue: 0,0:58:10.53,0:58:16.41,Default,,0000,0000,0000,,the current situation regarding TLS 1.3\Nand all those quantum-based algorithms
Dialogue: 0,0:58:16.41,0:58:21.72,Default,,0000,0000,0000,,that break the complexity into polynomial\Ntimes?
Dialogue: 0,0:58:21.72,0:58:26.95,Default,,0000,0000,0000,,Hanno: There's no major change here. So,\Nwith TLS 1.3 you still are using
Dialogue: 0,0:58:26.95,0:58:31.88,Default,,0000,0000,0000,,algorithms that can be broken with quantum\Ncomputers if you have a quantum computer.
Dialogue: 0,0:58:31.88,0:58:36.43,Default,,0000,0000,0000,,Which currently you don't, but you may\Nhave in the future. There is work done on
Dialogue: 0,0:58:36.43,0:58:42.42,Default,,0000,0000,0000,,standardizing future algorithms that are\Nsafe from quantum attacks, but that's kind
Dialogue: 0,0:58:42.42,0:58:47.03,Default,,0000,0000,0000,,of in an early stage. And there was an\Nexperiment by Google to introduce a
Dialogue: 0,0:58:47.03,0:58:53.72,Default,,0000,0000,0000,,quantum-safe handshake, but they only ran\Nit for a few months. But, I think we will
Dialogue: 0,0:58:53.72,0:58:57.41,Default,,0000,0000,0000,,see extensions within the next few years\Nthat will introduce quantum-safe
Dialogue: 0,0:58:57.41,0:59:03.37,Default,,0000,0000,0000,,algorithms, but right now there's no\Nchange from TLS 1.2 to 1.3. Both can be
Dialogue: 0,0:59:03.37,0:59:07.53,Default,,0000,0000,0000,,attacked with quantum computers.\NHerald: Okay, so I think we are getting to
Dialogue: 0,0:59:07.53,0:59:11.63,Default,,0000,0000,0000,,our last or second to last question, so\Nlet's go to mic 3, I think you've been
Dialogue: 0,0:59:11.63,0:59:16.94,Default,,0000,0000,0000,,waiting the longest.\NMic 3: Okay. In older versions of TLS
Dialogue: 0,0:59:16.94,0:59:23.49,Default,,0000,0000,0000,,there was a problem for small devices such\Nas IoT and the industrial devices. Has
Dialogue: 0,0:59:23.49,0:59:30.52,Default,,0000,0000,0000,,there been a change in 1.3 to allow them\Nto participate?
Dialogue: 0,0:59:30.52,0:59:33.31,Default,,0000,0000,0000,,Hanno: I mean I'm not sure what entirely\Nyou mean with the problem, I mean...
Dialogue: 0,0:59:33.31,0:59:37.90,Default,,0000,0000,0000,,Mic 3: Of performance, of performance.\NHanno: ...of course TLS needs some... the
Dialogue: 0,0:59:37.90,0:59:43.86,Default,,0000,0000,0000,,performance issues of TLS have usually\Nbeen overstated. So even in a relatively
Dialogue: 0,0:59:43.86,0:59:50.26,Default,,0000,0000,0000,,low-power device you can implement the\Ncrypto. I mean the whole protocol is
Dialogue: 0,0:59:50.26,0:59:55.20,Default,,0000,0000,0000,,relatively complex and you need to\Nimplement it somehow, but I don't think
Dialogue: 0,0:59:55.20,0:59:59.93,Default,,0000,0000,0000,,that's such a big issue anymore because\Neven IoT devices have relatively powerfull
Dialogue: 0,0:59:59.93,1:00:05.21,Default,,0000,0000,0000,,processors these days.\NHerald: Okay, alright, that concludes our
Dialogue: 0,1:00:05.21,1:00:10.35,Default,,0000,0000,0000,,Q&A, unfortunately we are out of time. So\Nplease give a huge round of applause for
Dialogue: 0,1:00:10.35,1:00:12.05,Default,,0000,0000,0000,,this great talk.
Dialogue: 0,1:00:12.05,1:00:15.04,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,1:00:15.04,1:00:20.20,Default,,0000,0000,0000,,{\i1}35C3 postroll music{\i0}
Dialogue: 0,1:00:20.20,1:00:37.71,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2019. Join, and help us!