1 00:00:00,000 --> 00:00:18,480 *35C3 preroll music* 2 00:00:18,480 --> 00:00:24,019 Herald-Angel: All right. Now it's my very big pleasure to introduce Hanno Böck to 3 00:00:24,019 --> 00:00:32,029 you. He's no stranger to the Chaos crowd. He's been to several Easterheggs and at 4 00:00:32,029 --> 00:00:38,500 several other Chaos events. Today he's here to talk about TLS 1.3, what it's all 5 00:00:38,500 --> 00:00:44,300 about how it came to be and what the future of it is gonna look like. Please 6 00:00:44,300 --> 00:00:57,560 give a huge applause and welcome Hanno. hanno: Yeah. Okay. So today I want to talk 7 00:00:57,560 --> 00:01:04,050 to you about a new version of TLS. TLS is this protocol, Transport Layer Security, 8 00:01:04,050 --> 00:01:09,780 which I hope everyone knows what it is. It's a protocol that you can put on top of 9 00:01:09,780 --> 00:01:15,990 other protocols that gives us an encrypted and authenticated channel through the 10 00:01:15,990 --> 00:01:25,500 generally insecure internet. We have a new version since August, TLS 1.3. At first 11 00:01:25,500 --> 00:01:31,130 I'd like to go a bit into the history of why we have this new version, how we got there 12 00:01:31,130 --> 00:01:40,750 and what design decisions were made for this version. So the very first version of 13 00:01:40,750 --> 00:01:47,490 SSL which it was called back then was released in 1995 by Netscape and it was 14 00:01:47,490 --> 00:01:54,550 quickly followed up with version 3 which is still very similar to the TLS 1.2 that 15 00:01:54,550 --> 00:02:01,380 we mostly use today. And then in 1999 it was kind of taken over from Netscape to 16 00:02:01,380 --> 00:02:05,810 the IETF, which is the Internet standardization organization, and they 17 00:02:05,810 --> 00:02:12,470 renamed it to TLS. And so that's kind of the history. We had SSL and I've marked it 18 00:02:12,470 --> 00:02:17,640 in red because these two versions are broken by design. You cannot really use 19 00:02:17,640 --> 00:02:22,770 them in a way that is secure these days because we know vulnerabilities that are 20 00:02:22,770 --> 00:02:31,080 part of the protocol. And then we had, in 1999 it was renamed to TLS, and TLS is 21 00:02:31,080 --> 00:02:35,690 kind of still kind of OK if you do everything right. But that's really 22 00:02:35,690 --> 00:02:40,880 tricky. So it's kind of a dangerous protocol but maybe not totally broken. 23 00:02:40,880 --> 00:02:46,930 Same with TLS 1.1. TLS 1.2 is what we still mostly use today and TLS 1.3 is the 24 00:02:46,930 --> 00:02:52,140 new one and what you can see here for example is that the the biggest gap here 25 00:02:52,140 --> 00:02:59,510 is between 1.2 and 1.3, so it was a very long time where we had no new development 26 00:02:59,510 --> 00:03:09,161 here. You probably heard that we had plenty of vulnerabilities in TLS, around 27 00:03:09,161 --> 00:03:16,080 TLS and also these days, a good vulnerability always has a logo and a nice 28 00:03:16,080 --> 00:03:23,240 name. And I want to go into one vulnerability which doesn't have a logo. 29 00:03:23,240 --> 00:03:29,230 Not one of the variants. I was very surprised when I realized that. That's the 30 00:03:29,230 --> 00:03:35,130 so-called Padding Oracles. They are in CBC mode which is the encryption we use for 31 00:03:35,130 --> 00:03:43,550 the actual data encryption, the symmetric data encryption. The thing is, when we 32 00:03:43,550 --> 00:03:51,130 encrypt data what we usually use are so- called block ciphers and they encrypt one 33 00:03:51,130 --> 00:04:00,230 block off a specific size of data. It's usually sixteen bytes and this CBC mode 34 00:04:00,230 --> 00:04:06,970 was the common way to encrypt in past TLS versions. And this is roughly how it looks 35 00:04:06,970 --> 00:04:11,470 like. So we have some initialization vector which should be random, but wasn't 36 00:04:11,470 --> 00:04:18,930 always, but that's another story. And then we encrypt a block of data and then we XOR 37 00:04:18,930 --> 00:04:27,190 that encryption into the next plain text and encrypt it again. Now one thing here 38 00:04:27,190 --> 00:04:32,390 is that because these are blocks of data and our data may not always be in sixteen 39 00:04:32,390 --> 00:04:38,040 byte blocks it may just be five bytes or whatever, we need to fill up that space. 40 00:04:38,040 --> 00:04:47,260 So we need some kind of padding. In TLS, what was done was that first of all we had 41 00:04:47,260 --> 00:04:53,150 some data. Then we added a MAC, which is something that guarantees the correctness 42 00:04:53,150 --> 00:04:58,090 of the data, the authentication of the data. And then we pad it up to a block 43 00:04:58,090 --> 00:05:02,950 size and then we encrypt it. And this order of things turned out to be very 44 00:05:02,950 --> 00:05:10,870 problematic. So this padding is a very simple method. If we have one byte to fill 45 00:05:10,870 --> 00:05:17,460 up we make a 00. If we have two bytes to fill up well you make 0101, three bytes 46 00:05:17,460 --> 00:05:27,530 020202 and so on. So that's easy to understand, right? Let's for a moment 47 00:05:27,530 --> 00:05:35,240 assume a situation where an attacker can manipulate data and can see whether the 48 00:05:35,240 --> 00:05:42,180 server receives a bad padding or whether it receives bad data, where this MAC check 49 00:05:42,180 --> 00:05:52,080 goes wrong. And here is the decryption with CBC mode. And what an attacker can do 50 00:05:52,080 --> 00:05:57,450 here: the first thing the attacker does, it throws one block away at the end, it 51 00:05:57,450 --> 00:06:04,270 just blocks the transmission of that block and then it changes something here. So 52 00:06:04,270 --> 00:06:11,160 what we assume here is the attacker wants to know this decrypted byte because it may 53 00:06:11,160 --> 00:06:17,970 contain some interesting data. So what he can do is he can manipulate this byte with 54 00:06:17,970 --> 00:06:27,250 a guess and a byte is only 256 values a byte can have. So he can guess enough 55 00:06:27,250 --> 00:06:36,330 times and XOR it with this value. And if you think about it if we XOR it here with 56 00:06:36,330 --> 00:06:40,889 the plaintext. That means if we end up with this zero here then the padding is 57 00:06:40,889 --> 00:06:46,419 valid. If we end up with some garbage value here, then the padding is probably 58 00:06:46,419 --> 00:06:54,940 invalid. So by making enough guesses the attacker can decrypt a byte here under the 59 00:06:54,940 --> 00:07:01,049 condition that he learns somehow whether the padding is valid or not. So he could 60 00:07:01,049 --> 00:07:06,930 decrypt one byte but he can't go on. Let's assume we will learn that one byte we have 61 00:07:06,930 --> 00:07:15,229 decrypted it and then we can go on with the next byte. So we XOR this byte on the 62 00:07:15,229 --> 00:07:22,800 right with the guess with what we already know that it is and with the one and. Then 63 00:07:22,800 --> 00:07:30,880 we XOR this next byte with our guess and also a one. And if this ends up being 0101 64 00:07:30,880 --> 00:07:35,941 then again we have a valid padding. So the attacker learns the next byte and he can 65 00:07:35,941 --> 00:07:44,110 do this for other bytes. This was originally discovered in 2002 by Sergey 66 00:07:44,110 --> 00:07:51,160 Vaudenay. But it was kind of only theoretical. So one thing here is that TLS 67 00:07:51,160 --> 00:07:57,910 has these error messages. There are different kinds of errors. And if you read 68 00:07:57,910 --> 00:08:06,110 through the TLS 1.0 standard, if the padding is wrong then you get this 69 00:08:06,110 --> 00:08:11,060 decryption_failed error. And if the MAC is wrong, so the data has some modification, 70 00:08:11,060 --> 00:08:15,590 then you get this bad_record_mac error. So you could say this would allow this 71 00:08:15,590 --> 00:08:22,410 Padding Oracle attack because there are these error messages. But the attacker 72 00:08:22,410 --> 00:08:26,160 cannot see them because they are encrypted. So this was kind of only a 73 00:08:26,160 --> 00:08:32,880 theoretical attack which didn't really work on a real TLS connection. But then 74 00:08:32,880 --> 00:08:37,770 there was a later paper which made this attack practical by measuring the timing 75 00:08:37,770 --> 00:08:42,948 difference from these different kinds of errors. And this allowed a practical 76 00:08:42,948 --> 00:08:52,249 decryption of TLS traffic. Then in later versions of TLS this was fixed or kind of 77 00:08:52,249 --> 00:08:57,460 fixed. But there is a warning in the standard which says.. So this is right 78 00:08:57,460 --> 00:09:02,160 from the standard text. "This leaves a small timing channel but it is not 79 00:09:02,160 --> 00:09:07,170 believed to be large enough to be exploitable." If you read something like 80 00:09:07,170 --> 00:09:16,149 that, it sounds maybe suspicious, maybe dangerous. And actually in 2013 there was 81 00:09:16,149 --> 00:09:20,180 these so-called Lucky Thirteen attack where a team of researchers actually 82 00:09:20,180 --> 00:09:26,199 managed to exploit that small timing side channel that the designers of the standard 83 00:09:26,199 --> 00:09:35,209 believed was not large enough to be exploitable. It is in theory possible to 84 00:09:35,209 --> 00:09:39,640 implement TLS in a way that it is safe from this timing attacks. But it adds a 85 00:09:39,640 --> 00:09:44,670 lot of complexity to the code. If you just look at when Lucky Thirteen was fixed, it 86 00:09:44,670 --> 00:09:51,939 just made the code much longer and much harder to understand. Then there was 87 00:09:51,939 --> 00:09:57,029 another Padding Oracle which was called POODLE, which was in the old version 88 00:09:57,029 --> 00:10:03,999 SSLv3. This was kind of by design. So the protocol was built in a way that you could 89 00:10:03,999 --> 00:10:11,100 not avoid this Padding Oracle. Then it turned out that there was also a kind of 90 00:10:11,100 --> 00:10:18,209 TLS variation of this POODLE attack. And the reason here was that the only major 91 00:10:18,209 --> 00:10:26,699 change between SSLv3 and TLS 1.0 was that the padding was fixed to a specific value, 92 00:10:26,699 --> 00:10:30,600 where in the past it could have any value. It turned out that there were TLS 93 00:10:30,600 --> 00:10:36,480 implementations that were not checking that, enabling this poodle attack also in 94 00:10:36,480 --> 00:10:44,880 TLS. Then there was the so-called Lucky Microseconds attack which was basically 95 00:10:44,880 --> 00:10:50,480 the.. one of the people who has found the Lucky Thirteen attack looked at 96 00:10:50,480 --> 00:10:55,930 implementations and saw if they have fixed Lucky Thirteen properly. They looked at 97 00:10:55,930 --> 00:11:01,339 s2n, which is an SSL library from Amazon and they found: "Ok, they tried to make 98 00:11:01,339 --> 00:11:04,829 countermeasures against this attack but these countermeasures didn't really work 99 00:11:04,829 --> 00:11:13,119 and they had still a timing attack that they could perform." Then there was a bug 100 00:11:13,119 --> 00:11:19,660 in OpenSSL which was kind of funny because when OpenSSL tried to fix this Lucky 101 00:11:19,660 --> 00:11:24,700 Thirteen attack, they introduced another Padding Oracle attack which was actually 102 00:11:24,700 --> 00:11:34,040 much easier to exploit. We had plenty of Padding Oracles. But if you remember back 103 00:11:34,040 --> 00:11:39,149 what I said, for the very first attack that this didn't really work in practice 104 00:11:39,149 --> 00:11:46,670 in TLS, because these errors are encrypted. But theoretically you could 105 00:11:46,670 --> 00:11:52,200 imagine that someone creates an implementation that sends errors that are 106 00:11:52,200 --> 00:12:02,250 not encrypted. For example you can send a TCP error or just cut the connection or 107 00:12:02,250 --> 00:12:06,499 have any kind of different behavior because the whole attack just relies on 108 00:12:06,499 --> 00:12:13,379 the fact that you can distinguish these two kinds of errors. You can find 109 00:12:13,379 --> 00:12:24,079 implementations out there doing that. So yeah, Padding Oracle is still an issue. 110 00:12:24,079 --> 00:12:27,839 Then I want to look at another attack which is a so-called Bleichenbacher 111 00:12:27,839 --> 00:12:33,019 attacks and they target the RSA encryption and that is kind of the asymmetric 112 00:12:33,019 --> 00:12:41,430 encryption which we use at the beginning of a connection to establish a shared key. 113 00:12:41,430 --> 00:12:52,260 This attack was found in 1998 by Daniel Bleichenbacher. If you look at the RSA 114 00:12:52,260 --> 00:13:01,569 encryption before we encrypt something with RSA, we do some preparations. The way 115 00:13:01,569 --> 00:13:09,750 this is done and in all TLS versions is these so-called PKCS #1 1.5 standard. How 116 00:13:09,750 --> 00:13:15,999 this looks is: it starts with the 00 02. Then we have some random data which is 117 00:13:15,999 --> 00:13:21,290 just again a padding to fill up space. Then we have zero which marks the end of 118 00:13:21,290 --> 00:13:27,680 the pending. Then we have a version number 03 03, which stands for TLS 1.2. It's 119 00:13:27,680 --> 00:13:33,279 totally obvious right. I'll get two version numbers later. And then we have 120 00:13:33,279 --> 00:13:38,779 the secret data. But the relevant thing for this attack is mostly this 00 02 at 121 00:13:38,779 --> 00:13:44,929 the beginning. So we know each correct encrypted block, if we decrypt it, it 122 00:13:44,929 --> 00:13:55,980 starts with 00 02. We may wonder if we implement a TLS server and it decrypts 123 00:13:55,980 --> 00:14:04,129 some data from the client and then it doesn't start with 00 02: what shall I do? 124 00:14:04,129 --> 00:14:07,989 And the naive thing would be: yeah of course we just send an error message 125 00:14:07,989 --> 00:14:14,389 because something is obviously wrong here. Now this turns out to be not such a good 126 00:14:14,389 --> 00:14:19,690 idea because if we do this we will tell the attacker something. We will tell him 127 00:14:19,690 --> 00:14:24,870 that the decrypted data does not start with 00 02. So the attacker learned 128 00:14:24,870 --> 00:14:30,170 something about the interval in which the decrypted data is. Either it starts with 129 00:14:30,170 --> 00:14:38,129 00 02 or it doesn't. And this turned out to be enough to.. if you send enough 130 00:14:38,129 --> 00:14:44,549 queries and modify the ciphertext you can learn enough information to decrypt data. 131 00:14:44,549 --> 00:14:48,669 The whole algorithm is a bit more complicated but it's not that complicated. 132 00:14:48,669 --> 00:14:52,809 It's relatively straightforward. It's a bit of math and I didn't want to put in 133 00:14:52,809 --> 00:15:01,279 any formulas but yeah. Now as I said it was discovered in 1998. So TLS 1.0 134 00:15:01,279 --> 00:15:07,129 introduced some countermeasures. The general idea here is that if you decrypt 135 00:15:07,129 --> 00:15:13,449 something and it is wrong then you're supposed to replace it with a random value 136 00:15:13,449 --> 00:15:19,170 and use that random value as your secret and pretend nothing has happened and then 137 00:15:19,170 --> 00:15:22,900 continue and then the handshake will fail later on because you don't have the same 138 00:15:22,900 --> 00:15:28,100 key. This prevents the attacker from learning whether your data is valid or 139 00:15:28,100 --> 00:15:35,109 not. In 2003 a research-team figured out that the countermeasures how they were 140 00:15:35,109 --> 00:15:39,839 described and TLS 1.0 were incomplete and also not entirely, it was not entirely 141 00:15:39,839 --> 00:15:44,779 clear how to implement them. Because there's this version-thing and it was not 142 00:15:44,779 --> 00:15:50,339 exactly described how to handle that. If only the version is wrong. So they they 143 00:15:50,339 --> 00:15:55,699 were able to make, to create an attack that still worked despite this 144 00:15:55,699 --> 00:16:03,970 countermeasures. So more countermeasures were proposed and in 2014 there was a 145 00:16:03,970 --> 00:16:09,610 paper that Java was still vulnerable to Bleichenbacher-attacks in a special way 146 00:16:09,610 --> 00:16:14,320 because they used some kind of decoding, then raised an exception. And the 147 00:16:14,320 --> 00:16:18,390 exception was long enough that you could measure the timing difference. And there 148 00:16:18,390 --> 00:16:23,519 was also still a small issue in OpenSSL although that was not practically 149 00:16:23,519 --> 00:16:32,649 exploitable. In 2016 there the so-called drown-attack. And the drown-attack was a 150 00:16:32,649 --> 00:16:37,519 Bleichenbacher-attack in SSL version 2. Now you may wonder SSL-version 2 is this 151 00:16:37,519 --> 00:16:44,499 very very old version from 1995. Is this a problem? But it actually is because you 152 00:16:44,499 --> 00:16:50,309 can use encrypted data from a modern TLS- version, TLS 1.2, and and decrypt it with 153 00:16:50,309 --> 00:16:58,850 a server that still supports SSL version 2. So that was the drown-attack. And then 154 00:16:58,850 --> 00:17:03,519 last year I thought maybe someone should check if there are still servers 155 00:17:03,519 --> 00:17:08,290 vulvernable to these Bleichenbacher- attacks. So I wrote a small scan tool and 156 00:17:08,290 --> 00:17:14,270 started scanning, and scanned the Alexa top-1000000. The first hit was 157 00:17:14,270 --> 00:17:21,349 Facebook.com was vulnerable and it turned out from the top-100 pages roughly 1/3 158 00:17:21,349 --> 00:17:25,869 were vulnerable. And in the end we found like 15 different implementations that 159 00:17:25,869 --> 00:17:37,090 were vulnerable. Probably more but these were the ones we know about. Yeah. And 160 00:17:37,090 --> 00:17:42,260 just I think a month ago there was another paper, that there also you can use cache- 161 00:17:42,260 --> 00:17:48,210 sidechannels which is mostly interesting if you have cloud-infrastructure where 162 00:17:48,210 --> 00:17:52,180 multiple servers are running on the same hardware, which you can also use to 163 00:17:52,180 --> 00:18:00,200 perform these Bleichenbacher-attacks. Now what I want to show you here: You cannot 164 00:18:00,200 --> 00:18:05,120 read this because it's too small but this is the chapters in the TLS-standard that 165 00:18:05,120 --> 00:18:09,880 describe the countermeasures to these Bleichenbacher-attacks. So we knew about 166 00:18:09,880 --> 00:18:14,620 them since before TLS 1.2, so there was a small chapter what you should do to 167 00:18:14,620 --> 00:18:18,410 prevent these attacks. And then they figured out: OK that's not enough. We need 168 00:18:18,410 --> 00:18:25,450 to have more countermeasures, and even more. So, what you can clearly see here is 169 00:18:25,450 --> 00:18:31,730 it's getting more and more complicated to prevent these attacks. So with every new 170 00:18:31,730 --> 00:18:40,550 TLS-version we had more complexity to prevent these Bleichenbacher-attacks. 171 00:18:40,550 --> 00:18:45,380 These were just two examples. There were a lot more attacks on TLS 1.2 and earlier 172 00:18:45,380 --> 00:18:50,920 that were due to poor design choices. I've named a few here: SLOTH, which was all 173 00:18:50,920 --> 00:18:56,620 against weak caches, FREAK which can attack issues in the handshake and 174 00:18:56,620 --> 00:19:03,680 compatibility with old versions, SWEET32 which attacks some block-ciphers that have 175 00:19:03,680 --> 00:19:08,800 a small blocksize, Triple-Handshake which is a very complicated interaction of 176 00:19:08,800 --> 00:19:18,160 different handshakes. The general trend here was that in TLS 1.2 and earlier, if 177 00:19:18,160 --> 00:19:23,151 there was a security bug, if there was a vulnerability in the cryptography, what 178 00:19:23,151 --> 00:19:29,110 people did was: We need a workaround for the security issue. And then if this 179 00:19:29,110 --> 00:19:35,340 workaround doesn't work it's not sufficient. We need more workarounds. And 180 00:19:35,340 --> 00:19:41,630 also we create more secure modes but we still keep the old ones. And then people 181 00:19:41,630 --> 00:19:45,580 can choose. We have this algorithm agility. You can choose, there's the 182 00:19:45,580 --> 00:19:52,460 secure algorithm, there's the less secure algorithm. Take whatever you want. Which 183 00:19:52,460 --> 00:19:56,240 in practice meant very often still the insecure modes were used because like for 184 00:19:56,240 --> 00:20:00,950 all of these things there were modes available in TLS 1.2 that didn't have 185 00:20:00,950 --> 00:20:09,900 these vulnerabilities. But they were optional. But, and I think that is the 186 00:20:09,900 --> 00:20:17,610 major change that came with TLS 1.3, was a mindset-change that people said, okay if 187 00:20:17,610 --> 00:20:22,300 something has vulnerabilities, if it's insecure and if we have something better 188 00:20:22,300 --> 00:20:29,980 then we just remove the thing that is vulnerable, that is problematic. So the 189 00:20:29,980 --> 00:20:35,390 main change in TLS 1.3 was that a lot of things were deprecated. So we no longer 190 00:20:35,390 --> 00:20:40,560 have these CBC-modes. We no longer have our RC4 which is another cipher which was 191 00:20:40,560 --> 00:20:48,770 problematic. We no longer have 3DES, which has these small blocksizes. We still use 192 00:20:48,770 --> 00:20:54,200 GCM but we no longer use it with an explicit nonce, which also turned out to 193 00:20:54,200 --> 00:21:00,330 be problematic. We completely remove RSA- encryption. We still use RSA but only for 194 00:21:00,330 --> 00:21:06,511 signatures. We remove hash-functions that turned out to be insecure. We remove 195 00:21:06,511 --> 00:21:13,280 Diffie-Hellman with custom parameters, which was, yeah, which turned out to be 196 00:21:13,280 --> 00:21:23,890 very problematic. And we removed ecliptic- curves that kind of look not so secure. 197 00:21:23,890 --> 00:21:31,420 But also there was something that some academics looked at TLS with the more 198 00:21:31,420 --> 00:21:36,380 scientific view. They tried to formally understand the security protocol, 199 00:21:36,380 --> 00:21:41,110 properties of this protocol and to analyze them to see if they can proof some kind of 200 00:21:41,110 --> 00:21:47,850 security properties of the protocol. And many vulnerabilities that I mentioned 201 00:21:47,850 --> 00:21:53,310 earlier were found by these researchers trying to formally analyze the protocol. 202 00:21:53,310 --> 00:22:01,370 But also these analyses have contributed to design TLS 1.3 to make it more robust 203 00:22:01,370 --> 00:22:07,270 to attacks. So this is, I think, also a big change. There was a much better 204 00:22:07,270 --> 00:22:12,300 collaboration between scientists who were looking at the protocol and the people who 205 00:22:12,300 --> 00:22:21,480 were actually writing the protocol. But you may see, all the security is nice but 206 00:22:21,480 --> 00:22:26,260 what we really care about or maybe some people really care about is speech, right. 207 00:22:26,260 --> 00:22:30,790 We want our internet to be fast. We want to open our browser and immediately get 208 00:22:30,790 --> 00:22:43,440 the page loaded. And TLS 1.3 also brings improved speed. And I am showing here the 209 00:22:43,440 --> 00:22:49,940 handshake. And this is very simplified. I have kind of only added the things that 210 00:22:49,940 --> 00:22:55,220 matter to make this point. But, if you look at on the left, if we do a handshake 211 00:22:55,220 --> 00:22:59,890 with an old TLS-version it starts that this client sends a client-hello, and some 212 00:22:59,890 --> 00:23:05,160 information, what version it supports, what encryption modes it's supports. Then 213 00:23:05,160 --> 00:23:09,810 the server sends back which encryption modes it wants to use and a key 214 00:23:09,810 --> 00:23:15,770 exchange. And then the client sends his part of the key exchange. And the so- 215 00:23:15,770 --> 00:23:19,460 called finished message and then the server sends a finished message and then 216 00:23:19,460 --> 00:23:27,000 the client can start sending data. In TLS 1.3 we have compressed this all a bit. The 217 00:23:27,000 --> 00:23:32,540 client sends his client-hello and immediately sends a key-exchange message. 218 00:23:32,540 --> 00:23:37,550 And then the server answers with his key- exchange message. And a few more things 219 00:23:37,550 --> 00:23:42,840 that I left out for simplicity. But the important thing is that with the second 220 00:23:42,840 --> 00:23:50,300 message the client can already send data. And this is the situation for a fresh 221 00:23:50,300 --> 00:23:55,000 handshake. Like we have not communicated before. I want to make a new connection to 222 00:23:55,000 --> 00:24:02,460 a server and it goes one time back and forth. And then I can send data. Which, 223 00:24:02,460 --> 00:24:07,330 and in the earlier version I had two times back and forth. So I can send data much 224 00:24:07,330 --> 00:24:18,300 faster. So yeah, we remove one round-trip from a fresh handshake. There's also 225 00:24:18,300 --> 00:24:23,550 security improvements to this handshake. So this is nice. We have more security and 226 00:24:23,550 --> 00:24:30,230 more speed. And particularly we have better security on so-called session- 227 00:24:30,230 --> 00:24:37,530 resumption, which means we're reconnecting using a key from a previous section. And 228 00:24:37,530 --> 00:24:42,780 we also protect more data which may avoid some attacks where an attacker may fiddle 229 00:24:42,780 --> 00:24:48,030 with the handshake. These were more or less theoretic attacks. But these are also 230 00:24:48,030 --> 00:24:57,020 prevented in TLS 1.3. Yeah. So TLS has a more secure and a faster handshake. And if 231 00:24:57,020 --> 00:25:01,120 you want to have more details about this handshake there was a talk two years ago 232 00:25:01,120 --> 00:25:06,410 at this congress, which goes into this in much more detail. So if this particularly 233 00:25:06,410 --> 00:25:10,140 interests you you should watch that talk. I've put a link here and I will put the 234 00:25:10,140 --> 00:25:19,870 slides online. There's also something called the zero-roundtrip-handshake. And 235 00:25:19,870 --> 00:25:26,360 this is even faster. We can send data right away. Now, how can we do that? This 236 00:25:26,360 --> 00:25:30,740 is kind of cheating because what we need here is we need to have a previous 237 00:25:30,740 --> 00:25:35,450 connection. And then we have a key from a previous connection, can create a new key 238 00:25:35,450 --> 00:25:42,040 from that and use that to send data right away. So yeah, we need a so-called 239 00:25:42,040 --> 00:25:47,250 preshared-key which we have from previous connection and then we can send data 240 00:25:47,250 --> 00:25:58,450 without any roundtrips. So, even more speed. That's nice, right. But this 0-RTT- 241 00:25:58,450 --> 00:26:04,740 mode does not come for free. There is a problem here with so-called replay- 242 00:26:04,740 --> 00:26:11,300 attacks, which means an attacker could record the data that we're sending and 243 00:26:11,300 --> 00:26:16,650 then send it again. And the server may think: Okay, now this request came twice. 244 00:26:16,650 --> 00:26:24,480 So I'm doing twice what this request was supposed to do. So there are some caveats 245 00:26:24,480 --> 00:26:29,450 with 0-RTT and the standard says you should only use if it's safe. It says 246 00:26:29,450 --> 00:26:36,710 something like you should only use it if you have a profile how to use it safely. 247 00:26:36,710 --> 00:26:43,620 Now what does that mean? There, let's look at https, the protocol we're using 248 00:26:43,620 --> 00:26:49,280 usually. If you look into the HTTP- standard it says something that a GET- 249 00:26:49,280 --> 00:26:55,470 request has to be idempotent and a POST- request does not have to be idempotent. 250 00:26:55,470 --> 00:26:59,780 Now what does that mean? It more or less means if you send a request twice it 251 00:26:59,780 --> 00:27:07,460 shouldn't do anything different from just sending it once. So in theory we could say 252 00:27:07,460 --> 00:27:13,180 yes a GET-requests are idempotent - that means they are safe for zero-roundtrip- 253 00:27:13,180 --> 00:27:23,230 connections. The question is, "do web- developers" ... Sorry. 254 00:27:23,230 --> 00:27:30,840 *applause* You can do a little experiment: If you 255 00:27:30,840 --> 00:27:34,970 meet someone who is a web developer, ask them if they know what idempotent means, 256 00:27:34,970 --> 00:27:42,910 and when they can use idempotent requests and when they cannot. So, in an ideal 257 00:27:42,910 --> 00:27:47,750 situation where web-developers do know that, we can use 0-RTT safely with TLS 258 00:27:47,750 --> 00:27:57,200 1.3. 0-RTT also does not have a strong forward secrecy as a normal handshake. So, 259 00:27:57,200 --> 00:28:02,090 there's kind of a tradeoff here, because this pre-shared key is encrypted with a 260 00:28:02,090 --> 00:28:06,300 key on the server and if that key gets compromised that may compromise our 261 00:28:06,300 --> 00:28:14,740 connection even if the key is only leaked later on. So, this looks a bit problematic 262 00:28:14,740 --> 00:28:19,900 and many speculate that the future attacks we'll see on TLS 1.3, that at least some 263 00:28:19,900 --> 00:28:24,470 of them will focus on this 0-RTT mode, because it looks like one of the more 264 00:28:24,470 --> 00:28:29,060 fragile parts of the protocol. But it gives us more speed., so people wanted to 265 00:28:29,060 --> 00:28:37,340 have it. Maybe the good news is, this is entirely optional; we don't have to use 266 00:28:37,340 --> 00:28:42,890 it; and if we think this looks too problematic, we can switch it off. So, if 267 00:28:42,890 --> 00:28:46,880 it turns out that there are too many attacks involving 0-RTT mode, we could 268 00:28:46,880 --> 00:28:51,560 disable it again and use it without it. It will still be faster, but not as fast as 269 00:28:51,560 --> 00:29:02,710 it could be with this. Okay. Deployment: Now, if we have this nice new protocol, we 270 00:29:02,710 --> 00:29:07,180 not only have to make sure it's secure and fast and everything, but we also have to 271 00:29:07,180 --> 00:29:16,430 deploy it. And we have to deploy it on the internet - on the real internet - like the 272 00:29:16,430 --> 00:29:19,530 one we have out there, not some theoretical internet where there are no 273 00:29:19,530 --> 00:29:24,000 bugs and everyone knows how to implement protocols, but the real internet with lots 274 00:29:24,000 --> 00:29:32,380 of IoT devices and enterprise firewalls and all these kinds of things. And now I 275 00:29:32,380 --> 00:29:40,660 want to get back to this version number. This may sound like a trivial thing, but 276 00:29:40,660 --> 00:29:49,810 TLS 1.3 has a new version number for the protocol version. Here's a Wireshark dump 277 00:29:49,810 --> 00:29:55,790 from a TLS 1.3 handshake. And if you're trying to look for the version number, you 278 00:29:55,790 --> 00:30:02,120 will find multiple version numbers. And in case you cannot see it, I have made it a 279 00:30:02,120 --> 00:30:13,550 bit larger. So at the top you see "Version: TLS 1.0", encoded as 0x0301. 280 00:30:13,550 --> 00:30:20,150 Okay. That looks strange. Then, a few lines later, you have "Version TLS: 1.2", 281 00:30:20,150 --> 00:30:27,840 0x0303. But we thought this was TLS 1.3... I mean it says here at the top but somehow 282 00:30:27,840 --> 00:30:34,000 there are these other versions. And then if you scroll further down, you will see 283 00:30:34,000 --> 00:30:40,120 "Extension: supported_versions". And then here it lists TLS 1.3, which is encoded as 284 00:30:40,120 --> 00:30:47,480 0x0304. So, what's going on here? This looks strange. So, the first thing to 285 00:30:47,480 --> 00:30:51,890 realize is why do we encode these versions in such a strange way; why are we not 286 00:30:51,890 --> 00:31:01,340 using 0x0100 for TLS 1.0? It's TLS 1.0 came after SSL version 3, which kind of 287 00:31:01,340 --> 00:31:08,679 makes it version 3.1; and that's how we encode it. TLS 1.0 is really just SSL 288 00:31:08,679 --> 00:31:17,960 version 3.1, TLS 1.1 is SSL version 3.2 and so on and for TLS 1.3, it's 289 00:31:17,960 --> 00:31:26,260 complicated. So, the very first version you saw earlier in this Wireshark dump was 290 00:31:26,260 --> 00:31:31,330 the so-called record layer and this is kind of a protocol inside the TLS protocol 291 00:31:31,330 --> 00:31:36,640 which has its own version number, which is totally meaningless but it's just there. 292 00:31:36,640 --> 00:31:41,230 And it turned out, for compatibility reasons, it's best to just let this on the 293 00:31:41,230 --> 00:31:46,380 version of TLS 1.0 and then, we have the least problems. And this is kind of... 294 00:31:46,380 --> 00:31:55,290 this record layer protocol is kind of the encoding of the TLS packages. Now, if we 295 00:31:55,290 --> 00:32:00,300 have a new TLS version, we cannot just tell everyone "tomorrow we will use TLS 296 00:32:00,300 --> 00:32:05,610 1.3" and everyone has to update, because we know many people won't. And so, we 297 00:32:05,610 --> 00:32:09,860 somehow need to be able to deploy this new version and still be compatible with 298 00:32:09,860 --> 00:32:19,840 devices that only speak the old version. So, let's assume we have a client that 299 00:32:19,840 --> 00:32:27,510 supports TLS 1.2, and we have a server that only supports TLS 1.0. How does that 300 00:32:27,510 --> 00:32:34,920 work? That's an extremely complicated mechanism here. So, the client connects 301 00:32:34,920 --> 00:32:44,270 and says "Hello. I speak TLS 1.2". Server says "Okay, I don't know TLS 1.2, but 302 00:32:44,270 --> 00:32:49,960 what's the highest version I support?" It's TLS 1.0, so he sents that back. And 303 00:32:49,960 --> 00:32:55,720 then, they can speak TLS 1.0 and - in case the client still supports that - and we 304 00:32:55,720 --> 00:33:06,290 have a connection. This is very simple. I would think so. So, to illustrate how you 305 00:33:06,290 --> 00:33:11,320 would program something like that, you would say "Yeah, if client_max_version is 306 00:33:11,320 --> 00:33:16,479 smaller than than server_max_version, then we use the client_max_version. Otherwise, 307 00:33:16,479 --> 00:33:23,600 we use the server_max_version. So, you would think that there's no way anyone 308 00:33:23,600 --> 00:33:31,820 could possibly not get that right, right? I mean, it's very simple. But I was saying 309 00:33:31,820 --> 00:33:36,360 earlier, we were talking about the real internet. So... And on the real internet, 310 00:33:36,360 --> 00:33:41,360 we have enterprise products. In case you don't know that, an enterprise product is 311 00:33:41,360 --> 00:33:44,160 something that's very expensive and it's buggy. 312 00:33:44,160 --> 00:33:55,130 *Laughter**Applause* hanno: So, yeah. We will have web pages 313 00:33:55,130 --> 00:34:00,660 that run with firewalls from Cisco or we will have people using IBM Domino web 314 00:34:00,660 --> 00:34:06,590 server and all these kinds of things. And this is the TLS version negotiation in the 315 00:34:06,590 --> 00:34:13,909 enterprise edition. So a client says "Yeah I want to connect with TLS 1.2" and the 316 00:34:13,909 --> 00:34:18,519 server says "Oh I don't support this this very new version. It's from 2008. I mean 317 00:34:18,519 --> 00:34:29,029 that's 10 years in Enterprise years. That's very long." So the server just 318 00:34:29,029 --> 00:34:33,549 sends an error if the client connects with the TLS version that it doesn't know. It 319 00:34:33,549 --> 00:34:38,829 doesn't implement this version negotiation correctly. And this is called version 320 00:34:38,829 --> 00:34:47,140 intolerance. This has happened every time there was a new TLS version. Every time we 321 00:34:47,140 --> 00:34:51,949 had devices that had this problem. If we tried to connect with the new TLS version 322 00:34:51,949 --> 00:34:54,829 they would just fail. They would send an error or they would just cut the 323 00:34:54,829 --> 00:35:03,460 connection or have a timeout or crash. So browsers needed to handle this somehow 324 00:35:03,460 --> 00:35:07,769 because the problem here is, when a browser introduces new TLS version and 325 00:35:07,769 --> 00:35:11,940 everything breaks, then users will blame the browser and then they will say "Yeah I 326 00:35:11,940 --> 00:35:15,539 will no longer use this browser, I'll now switch back to Internet Explorer" or 327 00:35:15,539 --> 00:35:23,890 something like that. So browsers needed to handle this somehow. What the browsers did 328 00:35:23,890 --> 00:35:30,049 was "Okay, we try it with the latest TLS version we support. And if we get an error 329 00:35:30,049 --> 00:35:35,339 we try it again with one version lower. And again one version lower and eventually 330 00:35:35,339 --> 00:35:41,401 we may succeed to connect." So here we have a browser and we have an enterprise 331 00:35:41,401 --> 00:35:49,969 server that supports TLS 1.0 and we will eventually get a connection. Do you 332 00:35:49,969 --> 00:35:56,040 remember POODLE I mentioned earlier? There was this padding oracle in SSLv3, which 333 00:35:56,040 --> 00:36:07,139 was discovered in 2014. You may wonder SSLv3 which is from 1996, that's really 334 00:36:07,139 --> 00:36:14,890 old. Who uses that in 2014? It was deprecated for 16 years. I mean who uses 335 00:36:14,890 --> 00:36:24,390 that? Windows Phone 7 used it. On this Nokia phones they also never got an 336 00:36:24,390 --> 00:36:35,630 update. Normal browsers and servers at least used TLS 1.0. They maybe didn't use 337 00:36:35,630 --> 00:36:44,839 TLS 1.2, but they used TLS 1.0. But we have these browsers that are trying to 338 00:36:44,839 --> 00:36:51,400 reconnect if there's an error. And so what an attacker could do is that the attacker 339 00:36:51,400 --> 00:36:58,470 wants to exploit SSLv3. So he just blocks all connections with the newer TLS version 340 00:36:58,470 --> 00:37:05,660 and therefore forces the client to go into SSLv3. And then he can exploit this attack 341 00:37:05,660 --> 00:37:18,819 that only works on SSLv3. These downgrades are causing security issues. What do we do 342 00:37:18,819 --> 00:37:24,930 now? We could add another work workaround. There was a standard called SCSV which 343 00:37:24,930 --> 00:37:31,789 basically gives the server a way to tell the client that it's not broken. It says 344 00:37:31,789 --> 00:37:40,470 "hey, I have this kind of special cipher suite" which tells the client "hey, if you 345 00:37:40,470 --> 00:37:46,010 did these strange downgrades here, please don't do that. I'm a well behaving 346 00:37:46,010 --> 00:37:51,869 server." So we had a workaround for broken servers and then we needed another 347 00:37:51,869 --> 00:37:57,020 workaround for the security issues caused by those workarounds. But at some points 348 00:37:57,020 --> 00:38:02,079 even enterprise servers mostly had fixed this version intolerance issues and 349 00:38:02,079 --> 00:38:10,099 browsers stopped doing these downgrades. Attacks like POODLE no longer worked. 350 00:38:10,099 --> 00:38:15,849 However I just said they fixed it. No of course they have not fixed it. I mean they 351 00:38:15,849 --> 00:38:21,311 fixed it for TLS 1.2. But of course they did not fix it for future TLS versions 352 00:38:21,311 --> 00:38:28,650 because they were not around yet. This TLS 1.3, we would get version intolerance 353 00:38:28,650 --> 00:38:33,130 again and breaking servers and would have to introduce downgrades again and all the 354 00:38:33,130 --> 00:38:42,109 nice security would not be very helpful. The TLS working group realized that and 355 00:38:42,109 --> 00:38:48,220 redesigned the handshake. It was redesigned in a way that the old version 356 00:38:48,220 --> 00:38:53,389 fields still said that we are connecting with TLS 1.2 and then we introduce an 357 00:38:53,389 --> 00:39:00,200 extension, supported_versions, which signals the support for all the TLS 358 00:39:00,200 --> 00:39:04,829 versions we can speak and which signals support for TLS 1.3 and possibly for 359 00:39:04,829 --> 00:39:12,720 future versions. Now at this point you may wonder if we'll have version intolerance 360 00:39:12,720 --> 00:39:18,430 with this new extension, once TLS 1.4 gets out because the server may be implemented 361 00:39:18,430 --> 00:39:23,019 that it sends an error if it sees an unknown version in this new version 362 00:39:23,019 --> 00:39:31,619 extension. David Benjamin from Google thought about this and said "Yeah we have 363 00:39:31,619 --> 00:39:36,710 to do something about that. We have to improve the future compatibility for 364 00:39:36,710 --> 00:39:44,839 future TLS versions." And he invented this GREASE mechanism. The idea here is, a 365 00:39:44,839 --> 00:39:50,070 server should just ignore unknown versions in this extension. He gets a list of TLS 366 00:39:50,070 --> 00:39:53,900 versions and if there's one in there that he doesn't know about, he should just 367 00:39:53,900 --> 00:40:00,859 ignore it and then connect with one of the versions he knows about. So we could kind 368 00:40:00,859 --> 00:40:07,430 of try to train servers to actually do that. And the idea here is we're just 369 00:40:07,430 --> 00:40:12,980 sending random bogus TLS versions that are reserved values that will never be used 370 00:40:12,980 --> 00:40:17,979 for a real TLS version. But we can just randomly add them to this extension in 371 00:40:17,979 --> 00:40:22,470 order to make sure that if a server implements this incorrectly, they will 372 00:40:22,470 --> 00:40:27,049 hopefully recognize that early because there will be connection failures with 373 00:40:27,049 --> 00:40:40,869 normal browsers. The hope here is if enterprise vendors will implement a broken 374 00:40:40,869 --> 00:40:45,089 version negotiation, they will hopefully notice that before they ship the product 375 00:40:45,089 --> 00:40:51,790 and then it can no longer be updated because that's how the Internet works. So 376 00:40:51,790 --> 00:40:55,839 we have this new version negotiation mechanism we no longer need these 377 00:40:55,839 --> 00:41:00,229 downgrades and we have this GREASE mechanism to make it future proof. So now 378 00:41:00,229 --> 00:41:17,481 we can ship TLS 1.3, right? Then there was this middle box issue. Oh sorry, that's a 379 00:41:17,481 --> 00:41:25,669 wrong year. It must be 2016, sorry. In 2016, in summer, TLS 1.3 was almost 380 00:41:25,669 --> 00:41:32,940 finished. But then it took almost another year till it got out. Oh sorry, I mixed up 381 00:41:32,940 --> 00:41:41,420 the years. It's correct. In 2017, when TLS 1.3 was almost finished, but it took until 382 00:41:41,420 --> 00:41:48,529 2018 until it was actually finished. The reason for that was that when browser 383 00:41:48,529 --> 00:41:54,660 vendors implemented a draft version of TLS 1.3, they noticed a lot of connection 384 00:41:54,660 --> 00:42:00,780 failures. And the reason for these connection failures turned out, were 385 00:42:00,780 --> 00:42:05,159 devices that were trying to analyze the traffic and trying to be smart. And they 386 00:42:05,159 --> 00:42:09,010 thought "OK this is something that looks very strange. It doesn't look like a TLS 387 00:42:09,010 --> 00:42:16,039 package how we're used to it. So let's just drop it, yeah?" So "Yeah, this is a 388 00:42:16,039 --> 00:42:22,889 strange TLS package, I don't know what to do with this, I'll drop it." These were 389 00:42:22,889 --> 00:42:26,480 largely passive middle boxes. So we're not talking about things like man in the 390 00:42:26,480 --> 00:42:30,069 middle devices that are intercepting a TLS connection but just something like a 391 00:42:30,069 --> 00:42:33,859 router, where you would expect it just forwards traffic. But it tries to be 392 00:42:33,859 --> 00:42:38,690 smart, it tries to do advanced security enterprise. I don't know. And they were 393 00:42:38,690 --> 00:42:46,940 dropping traffic that looked like TLS 1.3 Then the browser vendors proposed some 394 00:42:46,940 --> 00:42:56,910 changes to TLS 1.3 so it looks more like TLS 1.2. The main thing was, they 395 00:42:56,910 --> 00:43:03,460 introduced some bogus messages from TLS 1.2 that were supposed to be ignored. So 396 00:43:03,460 --> 00:43:08,490 one such message is the so-called ChangeCipherSpec message in TLS 1.2, which 397 00:43:08,490 --> 00:43:15,720 originally didn't exist in 1.3 due to this new handshake design. This message in 1.2, 398 00:43:15,720 --> 00:43:22,980 it signals that everything from now on is encrypted. The idea was "okay, if we sent 399 00:43:22,980 --> 00:43:28,359 a bogus ChangeCipherSpec message early in the handshake, then maybe this would 400 00:43:28,359 --> 00:43:32,560 confuse those devices, thinking everything after that is encrypted and they cannot 401 00:43:32,560 --> 00:43:38,349 analyze it." And it turned out this worked. A lot of this reduced the 402 00:43:38,349 --> 00:43:45,089 connection failures a lot. There are a few other things. And then eventually the 403 00:43:45,089 --> 00:43:52,339 failure rates got low enough that browsers thought "Okay, now we can deploy this." 404 00:43:52,339 --> 00:44:00,309 There were a few more issues. This is a Pixma printer from Canon. These things 405 00:44:00,309 --> 00:44:06,420 have an HTTPS server. They have network support. And we have to talk about these 406 00:44:06,420 --> 00:44:16,390 people here. If you remember the Snowden relations, one of the things that got 407 00:44:16,390 --> 00:44:20,180 highlighted there was that there's a random number generator called Dual EC 408 00:44:20,180 --> 00:44:25,710 DRBG. And that has a backdoor and basically these days everyone believes 409 00:44:25,710 --> 00:44:30,289 this is a backdoor by the NSA and they have some secret keys so they can predict 410 00:44:30,289 --> 00:44:39,660 what random values this RNG will output. Also what was in the Snowden documents was 411 00:44:39,660 --> 00:44:44,580 that at some point the NSA offered 10 million dollars to RSA security, so they 412 00:44:44,580 --> 00:44:55,509 implement this RNG. Then there was a proposal, a draft, for a TLS extension, 413 00:44:55,509 --> 00:45:02,979 called Extended Random, that adds some extra random numbers to the TLS handshake. 414 00:45:02,979 --> 00:45:08,190 Why? It wasn't really clear like it was just "Yeah we can do this." It was just a 415 00:45:08,190 --> 00:45:12,299 proposal. I mean everyone can write a proposal for a new extension, it was never 416 00:45:12,299 --> 00:45:20,609 finalized, but it was out there. And in 2014, a research team looked closer at 417 00:45:20,609 --> 00:45:29,420 this Dual EC RNG and figured out that if you use this ER extension then it's much 418 00:45:29,420 --> 00:45:39,290 easier to exploit this backdoor in this RNG. And coincidentally RSA's TLS library, 419 00:45:39,290 --> 00:45:45,329 BSAFE, also contains support for that extension. But it was switched off. They 420 00:45:45,329 --> 00:45:48,809 didn't find any implementations that actually used it. So it was thought of 421 00:45:48,809 --> 00:45:53,539 "okay, this was no big deal, all right". But actually it seems these these Canon 422 00:45:53,539 --> 00:46:00,729 printers, they had enabled this extension. They use this RSA BSAFE library and 423 00:46:00,729 --> 00:46:08,040 enabled this ER extension, which was only a draft. And so as ER was only a draft, it 424 00:46:08,040 --> 00:46:13,809 had no official extension number. So such a TLS extension has a number so that the 425 00:46:13,809 --> 00:46:19,089 server knows what kind of extension this is. And for this implementation they just 426 00:46:19,089 --> 00:46:24,059 used the next available number. And it turned out that this number collided with 427 00:46:24,059 --> 00:46:32,990 one of the mandatory extensions that TLS 1.3 introduced. So these these Canon 428 00:46:32,990 --> 00:46:36,319 printers could not interpret that new extension. They thought this is this 429 00:46:36,319 --> 00:46:45,289 Extended Random and it didn't make any sense, and so you had connection failures. 430 00:46:45,289 --> 00:46:50,050 In the TLS protocol they just gave this extension a new number and then this no 431 00:46:50,050 --> 00:46:58,009 longer happened. There were many more such issues and they continue to show up. For 432 00:46:58,009 --> 00:47:02,859 example recently, Java, which is like also very popular in enterprise environments, 433 00:47:02,859 --> 00:47:06,910 it now ships with TLS 1.3 support but it doesn't really work. So you have 434 00:47:06,910 --> 00:47:16,579 connection failures there. Now with all these deployment issues, what about future 435 00:47:16,579 --> 00:47:20,569 TLS versions? Will we have all that again? And we have this GREASE mechanism and it 436 00:47:20,569 --> 00:47:25,220 helps a bit like it prevents this version intolerance issues but it doesn't prevent 437 00:47:25,220 --> 00:47:32,349 these more complicated middle box issues. There was a proposal from David Benjamin 438 00:47:32,349 --> 00:47:36,099 from Google who said "Yeah, maybe we should just, every few months, like every 439 00:47:36,099 --> 00:47:40,989 two or three months, ship a new temporary TLS version which we will use for three 440 00:47:40,989 --> 00:47:47,770 months and then we will deprecate it again to just constantly change the protocol so 441 00:47:47,770 --> 00:47:51,150 that the Internet gets used to the fact that new protocols get introduced." 442 00:47:51,150 --> 00:47:56,920 *Laughter* My prediction here is that these 443 00:47:56,920 --> 00:48:01,030 deployment issues are going to get worse. I mean, we know now that they exist and we 444 00:48:01,030 --> 00:48:08,230 kind of have some ideas how to prevent them, but if you go to enterprise security 445 00:48:08,230 --> 00:48:13,859 conferences, you will know that the latest trend in enterprise security is this thing 446 00:48:13,859 --> 00:48:19,410 called artificial intelligence: We use machine learning and fancy algorithms to 447 00:48:19,410 --> 00:48:27,809 detect bad stuff. And that worries me. And here's a blog post from Cisco, where they 448 00:48:27,809 --> 00:48:32,569 want to use machine learning to detect bad TLS traffic, because they see all this 449 00:48:32,569 --> 00:48:37,220 traffic is encrypted and we can no longer analyze it, we don't know if malware in 450 00:48:37,220 --> 00:48:42,769 there, so let's use some machine learning; it will detect bad traffic. So, what I'm 451 00:48:42,769 --> 00:48:48,099 very worried that will happen here is that the next generation of TLS deployment 452 00:48:48,099 --> 00:48:53,319 issues will be AI-supported TLS intolerance issues and it may be much 453 00:48:53,319 --> 00:49:04,130 harder to fix and analyze. Speaking of enterprise environments, one of the very 454 00:49:04,130 --> 00:49:11,689 early changes in TLS 1.3 was that it removed the RSA encryption handshake. One 455 00:49:11,689 --> 00:49:15,259 reason was that it doesn't have forward secrecy. The other was these, all these 456 00:49:15,259 --> 00:49:23,150 Bleichenbacher attacks that I talked about earlier. And then, there came an email to 457 00:49:23,150 --> 00:49:31,190 the TLS working group from the banking industry and I quote: "I recently learned 458 00:49:31,190 --> 00:49:34,719 of a proposed change that would affect many of my organization's member 459 00:49:34,719 --> 00:49:40,170 institutions: the deprecation of the RSA key exchange. Deprecation of the RSA key 460 00:49:40,170 --> 00:49:44,140 exchange in TLS 1.3 will cause significant problems for financial institutions, 461 00:49:44,140 --> 00:49:48,600 almost all of whom are running TLS internally and have significant, security- 462 00:49:48,600 --> 00:49:54,869 critical investments in out-of-band TLS decryption." What it basically means is, 463 00:49:54,869 --> 00:49:59,119 they are using TLS for some connection; they have some device in the middle that 464 00:49:59,119 --> 00:50:05,869 is decrypting the traffic and analyzing it somehow which - if they do it internally - 465 00:50:05,869 --> 00:50:11,789 it's okay, but this no longer works with TLS 1.3, because we always negotiate a new 466 00:50:11,789 --> 00:50:20,900 key for each connection and it's no longer possible to have the static decryption. 467 00:50:20,900 --> 00:50:25,970 There was an answer from Kenny Patterson, he's a professor from London, he said: "My 468 00:50:25,970 --> 00:50:29,359 view concerning your request: no. Rationale: We're trying to build a more 469 00:50:29,359 --> 00:50:37,469 secure internet." *Applause* 470 00:50:37,469 --> 00:50:41,239 "You're a bit late to the party. We're metaphorically speaking at the stage of 471 00:50:41,239 --> 00:50:46,049 emptying the ash trays and hunting for the not quite empty beer cans. More exactly, 472 00:50:46,049 --> 00:50:50,559 we are at draft 15 and RSA key transport disappeared from the spec about a dozen 473 00:50:50,559 --> 00:50:55,619 drafts ago. I know the banking industry is usually a bit slow off the mark, but this 474 00:50:55,619 --> 00:51:00,700 takes the biscuit." Okay. *Laughter* 475 00:51:00,700 --> 00:51:07,900 There were several proposals then to add a visibility mode to TLS 1.3, which would in 476 00:51:07,900 --> 00:51:13,800 another way allow these connections that could be passively observed and decrypted, 477 00:51:13,800 --> 00:51:18,509 but they were all rejected and the general opinion in the TLS working group was that 478 00:51:18,509 --> 00:51:23,979 the goal of monitoring traffic content is just fundamentally not the goal of TLS. 479 00:51:23,979 --> 00:51:31,210 The goal of TLS is to have an encrypted channel that no one else can read. The 480 00:51:31,210 --> 00:51:37,900 industry eventually went to ETSI, which is the European technology standardization 481 00:51:37,900 --> 00:51:43,589 organization, and they recently published something called Enterprise TLS... 482 00:51:43,589 --> 00:51:51,369 *Laughter* ...which modifies TLS 1.3 in a way that it 483 00:51:51,369 --> 00:51:57,880 would allow these decryptions. The IETF protested against that and primarily 484 00:51:57,880 --> 00:52:02,979 because of the... they used the name TLS, because it sounds like this is some 485 00:52:02,979 --> 00:52:08,359 addition to TLS or something, and apparently ETSI has previously promised to 486 00:52:08,359 --> 00:52:14,340 them that they would not use the name TLS and then they named it Enterprise TLS. 487 00:52:14,340 --> 00:52:23,950 Okay, but yeah... TLS 1.3 is finished. You can start using it. You should update your 488 00:52:23,950 --> 00:52:29,799 servers so that they use it. Your browser probably already supports it. So, in 489 00:52:29,799 --> 00:52:41,170 summary: TLS 1.3 deprecates many insecure constructions. It's faster and deploying 490 00:52:41,170 --> 00:52:47,889 new things on the internet is a mess. So, yeah. That's it. And I think we have a few 491 00:52:47,889 --> 00:52:59,599 minutes for questions. *Applause* 492 00:52:59,599 --> 00:53:03,610 Herald: Alright, yeah. As Hanno mentioned, we have 6 minutes or so for questions. We 493 00:53:03,610 --> 00:53:07,750 have 5 microphones in the room. So, if you want to ask a question, hurry up to one of 494 00:53:07,750 --> 00:53:11,749 the microphones and please make sure to ask a short, concise question, so that we 495 00:53:11,749 --> 00:53:16,180 can get as many in as we can possibly can. Maybe, you just go ahead over there. Mic 496 00:53:16,180 --> 00:53:18,250 2. Mic 2: Thank you very much for this 497 00:53:18,250 --> 00:53:23,925 interesting talk. Is there a way to prevent the uses of this Enterprise TLS? 498 00:53:23,925 --> 00:53:27,489 Hanno: The question is if there is a way to prevent the use of that Enterprise TLS. 499 00:53:27,489 --> 00:53:33,210 Yes, there is, because the basic idea is that they will use a static Diffie-Hellman 500 00:53:33,210 --> 00:53:38,349 key exchange and if you just connect twice and see that they are using the same 501 00:53:38,349 --> 00:53:43,210 again, then you may reject that. Although the problem is, some servers may also use 502 00:53:43,210 --> 00:53:52,410 that for optimization. So, there are longer discussions on this question, so... 503 00:53:52,410 --> 00:53:57,489 I cannot fully answer it, but there more or less... there are options. 504 00:53:57,489 --> 00:54:00,470 Herald: Alright. Before we go to the next question, a quick request for all the 505 00:54:00,470 --> 00:54:05,019 people leaving the room: Please do so as quietly as possible, so we can finish this 506 00:54:05,019 --> 00:54:10,609 Q&A in peace and don't have all this noise going on. Mic 3, please. 507 00:54:10,609 --> 00:54:16,740 Mic 3: Hi. I was wondering about the replay attacks. Why didn't they implement 508 00:54:16,740 --> 00:54:21,860 something like sequence numbers into the TLS protocol? 509 00:54:21,860 --> 00:54:25,160 Hanno: Yeah. There is something like that in there. The problem is, you sometimes 510 00:54:25,160 --> 00:54:30,270 have a situation where you have multiple TLS termination points - for example, if 511 00:54:30,270 --> 00:54:34,110 you have a CDN network that is internationally distributed - and you may 512 00:54:34,110 --> 00:54:40,449 not be able to keep state across all of them. 513 00:54:40,449 --> 00:54:44,390 Herald: Alright. Then, let's take a question from our viewers in the internet. 514 00:54:44,390 --> 00:54:50,269 The signal angel, please. Signal angel: Alright. Binarystrike asks: 515 00:54:50,269 --> 00:54:55,329 "With regards to TLS 1.3 in the enterprise, shouldn't we move away from 516 00:54:55,329 --> 00:55:00,739 perimeter interception devices to also putting control on the end point, like we 517 00:55:00,739 --> 00:55:09,630 would have in a zero-trust environment?" Hanno: So, in my opinion, yes. But, there 518 00:55:09,630 --> 00:55:14,730 are many people in the enterise security industry who think that this is not 519 00:55:14,730 --> 00:55:20,269 feasible. But, I mean, discussion about network design, that would be a whole 520 00:55:20,269 --> 00:55:24,869 other talk. Yeah. Herald: Alright. Then, let's take a 521 00:55:24,869 --> 00:55:29,749 question from mic 4. Mic 4: Yeah. It's also related to the 522 00:55:29,749 --> 00:55:37,429 Enterprise TLS. The browser can connect to an Enterprise TLS server without any 523 00:55:37,429 --> 00:55:41,199 problems? Hanno: Yeah. So, it's built that it's 524 00:55:41,199 --> 00:55:46,589 compatible with the existing TLS protocol. Mic 4: Okay, thanks. 525 00:55:46,589 --> 00:55:50,049 Hanno: And the reason of whether you can avoid that or not, that's really a more 526 00:55:50,049 --> 00:55:54,279 complicated discussion, that would kind of be a whole sub-talk, so I cannot answer 527 00:55:54,279 --> 00:55:58,829 this in a minute, but come to me later if you are interested in details. 528 00:55:58,829 --> 00:56:01,679 Herald: Alright. Then, let's take another question from the interwebs. 529 00:56:01,679 --> 00:56:06,450 Signal Angel: We have one more question from IRC: "Would you recommend 530 00:56:06,450 --> 00:56:14,750 inserting bogus values into handshakes to train implementors?" 531 00:56:14,750 --> 00:56:18,710 Hanno: I mean that what I said what is done, that's actually what browsers are 532 00:56:18,710 --> 00:56:23,739 doing, and I think this is a good idea. I just think that this covers only a small 533 00:56:23,739 --> 00:56:29,339 fraction of these deployment issues. Herald: Okay, we still have plenty of 534 00:56:29,339 --> 00:56:34,819 time, so let's go to mic 2 please. Mic 2: Yeah, as you said, we have still a 535 00:56:34,819 --> 00:56:40,929 lot of dirty workarounds concerning TLS 1.3 and all the implementatons in the 536 00:56:40,929 --> 00:56:51,789 browers and so on. Is there a way to make, like, a requirement for the TLS 1.3 or 1.4 537 00:56:51,789 --> 00:57:01,319 compliance to meet some compliance to the standard? So you have like a test you can 538 00:57:01,319 --> 00:57:05,950 perform, a self-test or something like that and if you pass that you are allowed 539 00:57:05,950 --> 00:57:16,440 to use the TLS 1.3 logo or 1.4 logo. Hanno: You can do that in theory. The 540 00:57:16,440 --> 00:57:23,190 problem is you don't really want to have a certification regime that people like have 541 00:57:23,190 --> 00:57:28,859 to ask for a logo to be able to be allowed to implement TLS. and I mean that's kind 542 00:57:28,859 --> 00:57:32,530 of one of the downsides of the open architecture of the Internet, right? We 543 00:57:32,530 --> 00:57:36,419 allow everyone to put devices on the Internet, so we kind of have to live with 544 00:57:36,419 --> 00:57:43,819 that. And there's no TLS police, so, we kind of have no way of preventing people 545 00:57:43,819 --> 00:57:49,209 to use broken TLS implementations. And I mean people won't care if they have a logo 546 00:57:49,209 --> 00:57:54,539 for it or not, right? Herald: Alright, let's go to mic 5 all the 547 00:57:54,539 --> 00:57:58,749 way in the back there. Mic 5: Okay. I have a question about 548 00:57:58,749 --> 00:58:05,569 Shor's algorithm and TLS 1.3, because since quantum computing is getting very 549 00:58:05,569 --> 00:58:10,529 popular lately and there are a lot of improvements in the industries, so what's 550 00:58:10,529 --> 00:58:16,410 the current situation regarding TLS 1.3 and all those quantum-based algorithms 551 00:58:16,410 --> 00:58:21,719 that break the complexity into polynomial times? 552 00:58:21,719 --> 00:58:26,950 Hanno: There's no major change here. So, with TLS 1.3 you still are using 553 00:58:26,950 --> 00:58:31,880 algorithms that can be broken with quantum computers if you have a quantum computer. 554 00:58:31,880 --> 00:58:36,430 Which currently you don't, but you may have in the future. There is work done on 555 00:58:36,430 --> 00:58:42,420 standardizing future algorithms that are safe from quantum attacks, but that's kind 556 00:58:42,420 --> 00:58:47,029 of in an early stage. And there was an experiment by Google to introduce a 557 00:58:47,029 --> 00:58:53,719 quantum-safe handshake, but they only ran it for a few months. But, I think we will 558 00:58:53,719 --> 00:58:57,410 see extensions within the next few years that will introduce quantum-safe 559 00:58:57,410 --> 00:59:03,369 algorithms, but right now there's no change from TLS 1.2 to 1.3. Both can be 560 00:59:03,369 --> 00:59:07,530 attacked with quantum computers. Herald: Okay, so I think we are getting to 561 00:59:07,530 --> 00:59:11,630 our last or second to last question, so let's go to mic 3, I think you've been 562 00:59:11,630 --> 00:59:16,939 waiting the longest. Mic 3: Okay. In older versions of TLS 563 00:59:16,939 --> 00:59:23,490 there was a problem for small devices such as IoT and the industrial devices. Has 564 00:59:23,490 --> 00:59:30,519 there been a change in 1.3 to allow them to participate? 565 00:59:30,519 --> 00:59:33,310 Hanno: I mean I'm not sure what entirely you mean with the problem, I mean... 566 00:59:33,310 --> 00:59:37,900 Mic 3: Of performance, of performance. Hanno: ...of course TLS needs some... the 567 00:59:37,900 --> 00:59:43,859 performance issues of TLS have usually been overstated. So even in a relatively 568 00:59:43,859 --> 00:59:50,260 low-power device you can implement the crypto. I mean the whole protocol is 569 00:59:50,260 --> 00:59:55,200 relatively complex and you need to implement it somehow, but I don't think 570 00:59:55,200 --> 00:59:59,930 that's such a big issue anymore because even IoT devices have relatively powerfull 571 00:59:59,930 --> 01:00:05,210 processors these days. Herald: Okay, alright, that concludes our 572 01:00:05,210 --> 01:00:10,349 Q&A, unfortunately we are out of time. So please give a huge round of applause for 573 01:00:10,349 --> 01:00:12,049 this great talk. 574 01:00:12,049 --> 01:00:15,039 *applause* 575 01:00:15,039 --> 01:00:20,195 *35C3 postroll music* 576 01:00:20,195 --> 01:00:37,711 subtitles created by c3subtitles.de in the year 2019. Join, and help us!