Now it's my very big pleasure to introduce Hannu Berg to you.

He's no stranger to the Chaos crowd. He's been to several Easter hacks and several other Chaos events. Today he's here to talk about TLS 1.3, what it's all about, how it came to be, and

what the future of it is going to look like. Please give a huge applause and welcome Hannu.

Generally it's a scary event.

Since August, Chaos 1.3. I'd like to go a bit into the history, why we have this new version, how we got there, and what design decisions there were to make this new protocol version. So, the very first version of SSL, which it was called back then, was released in 1995

by Netscape, and it was quickly followed up with version 3, which is still very similar to the TLS 1.2 that we mostly use today. And then in 1999, it was kind of taken over from Netscape to the IETF, which is

the Internet Standardization Organization, and they renamed it to TLS. And so that's kind of the history. We had SSL, and I've marked it in red, because these two versions are broken by design. You cannot really use them in a way that is secure these days, because we know

vulnerabilities that are part of the protocol. Then we had, in 1999, it was renamed to TLS, and TLS is kind of, still kind of okay if you do everything right, but that's really tricky, so it's kind of a dangerous protocol, but maybe not totally broken, same with TLS 1.1.

TLS 1.2 is what we still mostly use today, and TLS 1.3 is the new one. And what you can see here, for example, is that the biggest gap here is between 1.2 and 1.3, so it was a very long time where we had no new development here.

Okay, you've probably heard that we had plenty of vulnerabilities in TLS, around TLS, and also these days, good vulnerability always has a logo and a nice name. And I want to go into one vulnerability which

doesn't have a logo, not one of the variants. I was very surprised when I realized that, but that's so-called padding oracles. They are in CBC mode, which is encryption we use for the actual data encryption, the symmetric data encryption.

So, the thing is, when we encrypt data, what we usually use are so-called block ciphers, and they encrypt one block of a specific size of data. It's usually 16 bytes, and this CBC mode was the common way to encrypt in past TLS versions.

And this is roughly how it looks like, so we have some initialization vector, which should be random, wasn't always, but that's another story. And then we encrypt a block of data, and then we XOR that encryption into the next plaintext and encrypt it again.

Now, one thing here is that, because these are blocks of data, and our data may not always be in 16-byte blocks, it may just be 5 bytes or whatever, we need to fill up that space, so we need some kind of padding. And in TLS, what was done was

that, first of all, we had some data, then we added a MAC, which is something that guarantees the correctness of the data, the authentication of the data. And then we pad it up to a block size, and then we encrypt it.

And this order of things turned out to be very problematic, so this padding is a very simple method, if we have one byte to fill up, we make a 00, if we have two bytes to fill up, we make a 11, three bytes to two, to two, to two, to two, and so on.

So that's easy to understand, right? Now, let's for a moment assume a situation where an attacker can manipulate data and can see whether the server receives a bad padding or whether it receives bad data

where this MAC check goes wrong. And here is the decryption with CBC mode. And what an attacker can do here, so the first thing the attacker does is throws one block away at the end. It just blocks the transmission of that block, and then he changes something here. So

what we assume here is the attacker wants to know this decrypted byte, because it may contain some interesting data. So what he can do is he can manipulate this byte with a guess, and the byte is only 256

values a byte can have, so he can guess enough times and exhort it with this value. And if you think about it, we exhort here with the plaintext. That means if we end up with a zero here, then the padding is valid. If we end up with some

garbage value here, then the padding is probably invalid. So by making enough guesses, the attacker can decrypt a byte here under the condition that he learns somehow whether the padding is valid or not. So he could decrypt one byte, but he can go on.

Let's assume we learned that one byte, we have decrypted it, and then we can go on with the next byte. So we exhort this byte on the right with the guess, with what we already know that it is, and with a one, and then we exhort

this next byte with our guess, and also a one. And if this ends up being one-one, then again we have a valid padding. So the attacker learns the next byte, and he can do this for other bytes. This was originally discovered in 2002 by Sergei Boudinny,

but it was kind of only theoretical. So one thing here is that TLS has these error messages, and there are different kinds of errors, and if you read up in the TLS 1.0 standard,

if the padding is wrong, then you get this decryption failed error, and if the MAC is wrong, so the data has some modification, then you get this bad record MAC error. So you could say this would allow this padding oracle attack, because there are these error messages, but the attacker

cannot see them because they are encrypted. So this was kind of only a theoretical attack, which didn't really work on a real TLS connection. But then there was a later paper which made this attack practical by measuring the timing difference from these different kinds of errors.

And this allowed practical decryption of TLS traffic. Then in later versions of TLS this was fixed, or kind of fixed, but there's a warning in the standard which says so this is right from the standard text, this leaves a small timing channel,

but it is not believed to be large enough to be exploitable. If you read something like that it sounds maybe suspicious, maybe dangerous, and actually in 2013 there was the so-called Lucky 13 attack, where a team of researchers actually managed to exploit that small timing side channel that

the designers of the standard believed was not large enough to be exploitable. And it is in theory possible to implement TLS in a way that is safe from these timing attacks, but it adds a lot of complexity to the code. If you just look at when Lucky 13

was fixed, it just made the code much longer and much harder to understand. Then there was another padding oracle which was called poodle, which was in the old version SSL3, and this was kind of by design, so the protocol was built in a way that you could not

avoid this padding oracle. Then it turned out that there was also kind of a TLS variation of this poodle attack, and the reason here was that the only major change between SSL version 3 and TLS version 1 was that the padding was

fixed to a specific value where in the past it could have any value, and it turned out that there were TLS implementations that were not checking that, enabling this poodle attack also in TLS. Then there was the so-called

Lucky Microseconds attack, which was basically one of the people who found the Lucky 13 attack looked at implementations and saw if they had fixed Lucky 13 properly, and they looked at S2N, which is an SSL library from Amazon, and they found, okay, they tried to make countermeasures against this attack, but these countermeasures didn't really work,

and they had still a timing attack that they could perform. Then there was a bug in OpenSSL, which was kind of funny because when OpenSSL tried to fix this Lucky 13 attack, they introduced another padding oracle attack, which

was actually much easier to exploit. So, yeah, we had plenty of padding oracles, but if you remember back what I said for the first attack, that this didn't really work in practice in TLS because

these errors are encrypted. But theoretically you could imagine that someone creates an implementation that sends errors that are not encrypted. For example, you can send a TCP error or just cut the connection or

have any kind of different behavior because the whole attack just relies on the fact that you can distinguish these two kinds of errors. And yeah, you can find implementations out there doing that. So, yeah, padding oracles are still an issue.

Then I want to look at another attack, which is so-called Bleychenbacher and they targeted the RSA encryption and that is kind of the asymmetric encryption, which we use at the beginning of a connection to establish a shared key. This attack was found

in 1998 by Daniel Bleychenbacher and if you look at the RSA encryption before we encrypt something with RSA, we do some preparations and the way this is done in all

TLS versions is the so-called PKCS1 1.5 standard and how this looks is it starts with 0.0.0.2 then we have some random data, which is just again a padding to fill up space then we have 0, which marks the end of the padding and then we have a version

number 0.3.0.3, which stands for TLS 1.2. It's totally obvious, right? I'll get to version numbers later. And then we have the secret data. But the relevant thing for this attack is mostly the 0.0.0.2 at the beginning. So we know each correct encrypted block if we

decrypt it, it starts with 0.0.0.2. So you may wonder if we implement a TLS server and it decrypts some data from the client and then it doesn't

start with 0.0.0.2. What shall it do? And the naive thing would be yeah, of course we just send an error message because something is obviously wrong here. Now this turns out to be not such a good idea because if we do this, we will tell the attacker something. We will tell him that the decrypted data

does not start with 0.0.0.2. So the attacker learns something about the interval in which the decrypted data is. Either it starts with 0.0.2 or it doesn't. And this turns out to be if you send enough queries and modify the cipher text, you can learn

enough information to decrypt data. The whole algorithm is a bit more complicated but it's not that complicated. It's relatively straightforward. It's a bit of math and I didn't want to put on any formulas. Now as I said it was discovered in 1998. So TLS 1.0

introduced some countermeasures and the general idea here is that if you decrypt something and it is wrong, then you're supposed to replace it with a random value and use that random value as your secret and pretend nothing has happened and then continue and then the handshake will fail later on

because you don't have the same key. This prevents the attacker from learning whether your data is valid or not. In 2003 a research team figured out that the countermeasures how they were described in TLS 1.0 were incomplete and also not entirely clear how to implement them

because there's this version thing and it was not exactly described how to handle that if only the version is wrong and other things. So they were able to create an attack that still worked despite these countermeasures. So more countermeasures were proposed and

in 2014 there was a paper that Java was still vulnerable to attacks in a special way because they used some kind of decoding that raised an exception and the exception was long enough that you could measure the timing difference and there was also still a small issue in OpenSSL although that was

not practically exploitable. In 2016 there was a so called Drown Attack and the Drown Attack was a black and black attack in SSL version 2. Now you may wonder, SSL version 2 is this very very old version from 1995. Is this a problem?

But it actually is because you can use encrypted data from a modern TLS version, TLS 1.2 and decrypt it with a server that still supports SSL version 2. So that was the Drown Attack and then last year I thought maybe someone should check if there are still servers

vulnerable to these Blythe and buffer attacks. So I wrote a small scan tool and started scanning and scanned the Alexa top 1 million. The first hit was Facebook Con was vulnerable and it turned out from the top 100 pages roughly a third were vulnerable and in the end

we found like 15 different implementations that were vulnerable. Probably more but these were the ones we know about. And just I think a month ago there was another paper that you can

use cache side channels which is mostly interesting if you have cloud infrastructure where multiple servers are running on the same hardware which you can also use to perform these Blythe and buffer attacks. Now what I want to show you here you cannot read this

because it's too small but this is the chapters in the TLS standard that describe the countermeasures to these Blythe and buffer attacks. So we knew about them since before TLS 1.0 so there was a small chapter what you should do to prevent these attacks and then they figured out ok that's not enough we need to have more countermeasures and even more. So what you can clearly see here

it's getting more and more complicated to prevent these attacks. So with every new TLS version we had more complexity to prevent these Blythe and buffer attacks. These were just two examples there were a lot more attacks on TLS 1.2 and earlier

that were due to poor design choices I've named a few here sloth which was also against vcaches, freak which can attack issues in the handshake and compatibility with old versions, sweet32 which

attacks some block ciphers that have a small block size, triple handshake which is a very complicated interaction of different handshakes The general trend here was that in TLS 1.2 and earlier if there was a security bug if there was a

vulnerability in the cryptography what people did was we need a workaround for the security issue and then if this workaround doesn't work it's not sufficient we need more workarounds and also we create more secure modes but we still keep the old ones and then people can choose we have this algorithm agility

you can choose there's the secure algorithm there's the less secure algorithm take whatever you want which in practice meant very often still the insecure modes were used because like for all of these things there were modes available in TLS 1.2 that didn't have these vulnerabilities but they were optional

I think that is the major change that came with TLS 1.3 was a mindset change that people said okay if something has vulnerabilities if it's insecure and if we

have something better then we just remove the thing that is vulnerable that is problematic so the main change in TLS 1.3 was that a lot of things were deprecated so we no longer have these CB-SIL modes we no longer have RC4 which is another cipher which was problematic

we no longer have triple des which has these small block sizes we still use GCM but we no longer use it with an explicit non-switch also turned out to be problematic we completely removed RSA encryption we still use RSA but only for signatures

we removed hash functions that turned out to be insecure we removed Diffie-Hellman with custom parameters which turned out to be very problematic and we removed elliptic curves that looked not so secure

but also there was something that some academics looked at TLS with the more scientific view they tried to formally understand the security protocol properties of this protocol and to analyze and to see if they can prove some kind of security

properties of the protocol and many vulnerabilities that I mentioned earlier were found by these researchers trying to formally analyze the protocol but also these analyses have contributed to design TLS 1.3 to make it more robust to attacks

so this is I think also a big change there was a much better collaboration between scientists who were looking at the protocol and the people who were actually writing the protocol but you may say yeah all this security is nice but

what we really care about or maybe some people really care about is speed we want our internet to be fast we want to open our browser and immediately get the page loaded and TLS 1.3 also brings improved speed and

I'm showing here the handshake and this is very simplified I've kind of only added the things that matter to make this point but if you look on the left if we do a handshake with an old TLS version it starts that this client sends a client hello and some information what version it supports

what encryption modes it supports then the server sends back which encryption modes it wants to use and a key exchange and then the client sends his part of the key exchange and the so called finished message and then the server sends a finished message and then the client can start sending data

in TLS 1.3 we have compressed this all a bit the client sends his client hello and immediately sends a key exchange message and then the server answers with his key exchange message and a few more things that I left out for simplicity but the important thing is that

with the second message the client can already send data and this is the situation for a fresh handshake like we have not communicated before I want to make a new connection to a server and it goes one time back and forth and then I can send data

which and in the earlier version I had two times back and forth so I can send data much faster so yeah we remove one round trip from a fresh handshake there is also security improvements to this handshake so this is nice we have more security

and more speed and particularly we have better security on so called session resumption which means we are reconnecting using a key from a previous section and we also protect more data which may avoid some attacks where an attacker may fiddle with the handshake

these were more or less theoretical attacks but these are also prevented in TLS 1.3 so TLS has a more secure and a faster handshake and if you want to have more details about this handshake there was a talk two years ago at this

congress which goes into this in much more detail so if this particularly interests you you should watch that talk I have put a link here and I will put the slides online there is also something called the zero round trip handshake and this is even faster we can send data right away

now how can we do that this is kind of cheating because what we need here is we need to have a previous connection and then we have a key from a previous connection can create a new key from that and use that to send data right away so yeah we need a so called pre-shared key which

we have from previous connection and then we can send data without any round trips so even more speeds that's nice right but this zero RTT mode does not come for free there is a problem here with so called

replay attacks which means an attacker could record the data that we are sending and then send it again and the server may think ok now this request came twice so I am doing twice what this request was supposed to do

so there are some caveats with zero RTT and the standard says yeah you should only use if it's safe it says something like you should only use it if you have a profile how to use it safely now what does that mean let's look at HTTPS which is the protocol we are using usually

if you look into the HTTP standard it says something that a GET request has to be idempotent and a POST request does not have to be idempotent now what does that mean it more or less means if you send a request twice it shouldn't do anything different from just sending it once

so in theory we could say yeah GET requests are idempotent that means they are safe for zero round trip connections the question is do web developers

you can do a little experiment if you meet someone who is a web developer ask them if they know what idempotent means and when they can use idempotent requests and when they cannot

so in an ideal situation where web developers do know that we can use zero RTT safely with TLS 1.3 zero RTT also does not have as strong forward secrecy as a normal handshake so there is kind of a trade off here because this pre-shared key is encrypted

with a key on the server and if that key gets compromised that might compromise our connection even if the key is only leaked later on so this looks a bit problematic and many speculate that the future attacks we will see on TLS 1.3 that at least some of them will focus on the zero RTT

mode because it looks like one of the more fragile parts of the protocol but it gives us more speed so people want it to have it maybe the good news is that this is entirely optional we don't have to use it and if we think this looks too problematic we can switch it off

so if it turns out that there are too many attacks involving zero RTT mode we could disable it again and use it without it, it will still be faster but not as fast as it could be with this deployment, now if we have this nice new protocol we not only

have to make sure it's secure and fast and everything but we also have to deploy it and we have to deploy it on the internet and on the real internet like the one we have out there not some theoretical internet where there are no bugs and everyone knows how to implement protocols

but the real internet with lots of IoT devices and enterprise firewalls and all these kinds of things and now I want to get back to this version number this may sound like a trivial thing but

TLS 1.3 has a new version number for the protocol version here's a wire shark dump from a TLS 1.3 handshake and if you're trying to look for the version number you will find multiple version numbers and in case you cannot see it I have made it

a bit larger so at the top you see version TLS 1.0 encoded as 0.3.0.1 okay that looks strange then a few lines later you have version TLS 1.2 0.3.0.3

but we thought this was TLS 1.3 I mean it says here at the top but somehow there are these other versions and then if you scroll further down you will see extension supported versions and then here it lists TLS 1.3 which is encoded as 0.3.0.4

so what's going on here this looks strange so the first thing to realize is why do we encode these versions in such a strange way why are we not using 0.1.0 for TLS 1.0 TLS 1.0 came after SSL version 3 which kind of makes it version 3.1

and that's how we encode it like TLS 1.0 is really just SSL version 3.1 TLS 1.1 is SSL version 3.2 and so on and for TLS 1.3 it's complicated

so the very first version you saw earlier in this wire shark dump was the so called record layer and this is kind of a protocol inside the TLS protocol which has it's own version number which is totally meaningless but it's just there and it turned out for compatibility reasons it's best to just let this on

the version of TLS 1.0 and then we have the least problems and this record layer protocol is kind of the encoding of the TLS packages now if we have a new TLS version we cannot just tell everyone tomorrow we will use TLS 1.3

and everyone has to update because we know many people won't and so we somehow need to be able to deploy this new version and still be compatible with devices that only speak the old version so let's assume we have a client that supports TLS 1.2 and we have a server that only

supports TLS 1.0 how does that work there's an extremely complicated mechanism here so the client connects and says hello I speak TLS 1.2 server says ok I don't know TLS 1.2 but what's the

highest version I support it's TLS 1.0 so he sent that back and then they can speak TLS 1.0 and in case the client still supports that and we have a connection

this is very simple I would think so to illustrate how you would program something like that you would say yeah if client max version is smaller than server max version then we use the client max version otherwise we use the server max version so

you would think that there's no way anyone could possibly not get that right I mean it's very simple but I was saying earlier we were talking about the real internet and on the real internet we have enterprise products in case you don't know that an enterprise

product is something that's very expensive and it's buggy so yeah we will have web pages that run with firewall from Cisco or we will have people using IBM domino web server

and all these kinds of things and this is the TLS version negotiation in the enterprise edition so a client says yeah I want to connect with TLS 1.2 and the server says oh I don't support this very new version it's from 2008 I mean that's 10 years in enterprise that's very long

so yeah so the server just sends an error if the client connects with the TLS version that it doesn't know it doesn't implement this version negotiation correctly and this is called version intolerance and

this has happened every time there was a new TLS version every time we had devices that had this problem if you try to connect with a new TLS version they would just fail they would send an error or they would just cut the connection or have a timeout or crash so browsers

needed to handle this somehow because the problem here is when a browser introduces a new TLS version and everything breaks then users will blame the browser and then they will say yeah I will no longer use this browser I'll now switch back to Internet Explorer or something like that so browsers needed to handle this somehow

so what the browsers did is okay we try it with the latest TLS version we support and if we get an error we try it again with one version lower and again one version lower and eventually we may succeed to connect so here we have a browser and we have an

enterprise server that supports TLS 1.0 and we will eventually get a connection now do you remember Poodle I mentioned earlier there was this padding oracle in SSL version 3 which was discovered in 2014 so

you may wonder SSL version 3 which is from 1996 so that's really old who uses that in 2014 it was deprecated for 16 years I mean who uses that Windows Phone 7 used it but

on these Nokia phones they also never got an update but like normal browsers and servers at least use TLS 1.0 I mean they maybe didn't use TLS 1.2 but they used TLS 1.0 but

we have these browsers that are trying to reconnect if there is an error and so what an attacker could do is that the attacker wants to exploit SSL version 3 so he just blocks all connections with a newer TLS version and therefore forces the client to go into

SSL version 3 and then he can exploit this attack that only works on SSL version 3 so these downgrades are causing security issues what do we do now we could add another workaround so there was a standard called SDSV

which basically gives the server a way to tell the client that it's not broken like it says hey I have this this special extension it's a kind of special cipher suite which tells the client hey if you did these strange downgrades here please don't do that

I'm a well behaving server so yeah we had a workaround for broken servers and then we needed another workaround for the security issues caused by those workarounds but at some points even enterprise servers mostly had fixed these version intolerance issues and browsers stopped doing these downgrades so

attacks like poodle no longer worked have I just said they fixed it no of course they have not fixed it I mean they fixed it for TLS 1.2 but of course they did not fix it for future TLS versions because they were not around yet so

with TLS 1.3 we would get version intolerance again and breaking servers and would have to introduce downgrades again and all the nice security would not be very helpful so the TLS working

group realized that and redesigned the handshake and it was redesigned in a way that the old version field still said that we're connecting with TLS 1.2 and then we introduced an extension supported versions which signals the support for which for all the TLS

versions we can speak and which signals support for TLS 1.3 and possibly for future versions now at this point you may wonder if we'll have version intolerance with this new extension once TLS 1.4 gets out because the server may be implemented that it sends an error if it sees an

unknown version in this new version extension and David Benjamin from Google thought about this and said yeah we have to do something about that we have to improve the future compatibility for future TLS versions and he invented this grease mechanism and

the idea here is okay a server should just ignore unknown versions in this extension he gets a list of TLS versions and if there's one in there that he doesn't know about he should just ignore it and then connect with one of the versions he knows about so we could kind of try to train servers to actually do

that and the idea here is we're just sending random bogus TLS versions that are reserved values that will never be used for a real TLS version but we can just randomly add them to this extension in order to make sure that if a server implements this incorrectly they will hopefully

recognize that early because there will be connection failures with normal browsers yeah so the hope here is if enterprise vendors will implement a broken

version negotiation they will hopefully notice that before they ship the product and then it can no longer be updated because that's how the internet works okay so we have this new version negotiation mechanism we no longer need these downgrades and we have this grease mechanism to make it future proof so now we can ship

TLS 1.3 right? then there was this metal box issue so oh sorry that's that's a wrong year it must be 2016 sorry

in 2016 TLS 1.3 was almost finished but then it took almost another year till it got sorry I mixed up the yes now it's correct in 2017 TLS 1.3 was almost finished but

it took till 2018 till it was actually finished and the reason for that was that when browser vendors implemented a draft version of TLS 1.3 they noticed a lot of connection failures and the reason for these connection failures turned out were devices that were trying to analyze the traffic and trying to be

smart and they thought okay this is something that looks very strange it doesn't look like a TLS package how we're used to it so let's just drop it yeah so yeah this is a strange TLS package I don't know what to do with this I'll drop it these were largely passive metal boxes

so we're not talking about things like man in the middle devices that are intercepting a TLS connection but just something like a router where you would expect it just forwards traffic but it tries to be smart it tries to do advanced security enterprise I don't know and they were dropping traffic that looked like TLS 1.3 and then

the browser vendors proposed some changes to TLS 1.3 so it looks more like TLS 1.2 and the main thing was they introduced some bogus messages from TLS 1.2 that were just supposed to be ignored so one such message is the so called

change cipher spec message in TLS 1.2 which originally didn't exist in 1.3 due to this new handshake design and this message in 1.2 it signals that everything from now on is encrypted

so the idea was okay if we send a bogus change cipher spec message early in the handshake then maybe this will confuse those devices thinking everything after that is encrypted and they cannot analyze it so yeah and it turned out this worked a lot of this reduced the connection failures a lot

so and there was a few other things and then eventually the failure rates got low enough that the browser thought okay now we can deploy this there were a few more issues this is a PIXMA printer from Canon these things have an HTTPS server they have network support

and we have to talk about these people here so if you remember the Snowden relations one of the things that got highlighted there was that there is a random number generator called dual EC DRBG

and that has a vector and basically these days everyone believes this is a vector by the NSA and they have some secret keys so they can predict what random values this random number generator will output and also what was in the Snowden documents was that at some point

the NSA offered 10 million dollars to RSA security so they implement this random number generator and then there was a proposal a draft for TLS extension called extended random that adds some extra random numbers to the TLS handshake

why it wasn't really clear like it was just yeah we can do this it was just a proposal I mean everyone can write a proposal for a new extension it was never finalized but it was out there and in 2014 research team looked closer at this

dual EC random number generator and figured out that if you use this extended random extension then it's much easier to exploit this vector in this random number generator and coincidentally RSA's TLS library b-safe also contains support for that

extension but it was switched off so and they didn't find any implementations that actually used it so it was thought of ok this was no big deal right but actually it seems these canon printers they had enabled this extension and they used this RSA b-safe library and enabled this

extended random extension which was only a draft and so as extended random was only a draft it had no official extension number so such a TLS extension has a number so that the server knows what kind of extension this is and for this implementation they just used the next available number

and it turned out that this number collided with one of the mandatory extensions that TLS 1.3 introduced so these canon printers could not interpret that new extension they thought this is this extended random and it didn't make any sense and so you had connection failures

yeah eventually so then in the TLS protocol they just gave this extension a new number and then this no longer happened yeah there were many more such issues and they continue to show up for example recently Java which is like also very

popular in enterprise environments it now ships with TLS 1.3 support but it doesn't really work so you have connection failures there yeah now with all these deployment issues what about future TLS versions will we have all that again and we have this grease mechanism and it helps a bit like it prevents these version tolerance

issues but it doesn't prevent these more complicated metal box issues there was a proposal from David Benjamin from Google who said yeah maybe we should just every few months like every two or three months ship a new temporary TLS version which we will use for three months and then we will deprecate

it again to just constantly change the protocol so that the internet gets used to the fact that new protocols get introduced my prediction here is that these deployment issues are going to get worse I mean we know now that they exist and we kind of have some ideas how to prevent them

but if you go to enterprise security conferences you will know that the latest trend in enterprise security is this thing called artificial intelligence we use machine learning and fancy algorithms to detect bad stuff and that

worries me and here's a blog post from Cisco where they want to use machine learning to detect bad TLS traffic because they say all this traffic is encrypted and we can no longer analyze it we don't know if malware is in there so let's use some machine learning it will detect bad traffic so what I'm very

worried that will happen here is that the next generation of TLS deployment issues will be AI supported TLS intolerance issues and it may be much harder to fix and analyze speaking of enterprise

environments one of the very early changes in TLS 1.3 was that it removed the RSA encryption handshake one reason was that it doesn't have forward secrecy the other was these all these that I talked about earlier and then there came an email

to the TLS working group from the banking industry and I quote I recently learned of a proposed change that would affect many of my organization's member institutions the deprecation of the RSA key exchange deprecation of the RSA key exchange in TLS 1.3 will cause significant problems for

financial institutions almost all of whom are running TLS internally and have significant security critical investments in out of band TLS decryption what it basically means is they are using TLS for some connection they have some device in the middle that is decrypting the traffic and analyzing it somehow

which if they do it internally it's okay but this no longer works with TLS 1.3 because we always negotiate a new key for each connection and it's no longer possible to have the static decryption there was an answer from Kenny Patterson

a professor from London said my view concerning your request no rational we're trying to build a more secure internet you're a bit late to the party we're metaphorically speaking at the stage of emptying the ashtrays

and hunting fauna not quite empty beer cans more exactly where draft 15 and RSA key transport disappeared from the spec on about a dozen drafts ago I know the banking industry is usually a bit slow off the mark but this takes a bit okay

there were several proposals then to add a visibility mode to TLS 1.3 which would in another way allow these connections that could be passively observed and decrypted but they were all rejected and the general opinion in the TLS working group was that the goal of monitoring traffic content is just fundamentally

not the goal of TLS the goal of TLS is to have an encrypted channel that no one else can read the industry we eventually went to Etsy which is the European technology standardization organization and they recently published

something called enterprise TLS which modifies TLS 1.3 in a way that it would allow these decryptions the IETF protested against that and primarily because of the use the name TLS because it sounds like this

is some addition to TLS or something and apparently Etsy has previously promised to them that they would not use the name TLS and then they named it enterprise TLS okay but yeah TLS 1.3 is finished you can start

using it you should update your servers so that they use it your browser probably already supports it yeah so in summary TLS 1.3 deprecates many insecure constructions it's faster and deploying new things

on the internet is a mess so yeah that's it and I think we have a few minutes for questions as Hanno mentioned we have like six minutes or so for questions we have five microphones in the room

so if you want to ask a question hurry up to one of the microphones and please make sure to ask a short concise question so we can get as many in as we possibly can maybe you just go ahead over there at the mic too thank you very much for this interesting talk is there a way to prevent the uses of that enterprise TLS?

the question is if there is a way to prevent the use of that enterprise TLS yes there is because the basic idea is that they will use a static Diffie-Hellman key exchange and if you just connect twice and see that they are using the same again then you may reject that although the problem

is some servers may also use it for optimization so there are longer discussions on this question so I cannot fully answer it but there are more or less options alright before we go to the next question a quick request for all the people leaving the room please do so

as quietly as possible so we can finish this Q&A in peace and don't have all these noise going on mic 3 please I was wondering about the replay attacks why didn't they implement something like sequence numbers into the TLS protocol

there is something like that in there the problem is you sometimes have a situation where you have multiple TLS termination points for example if you have a CDN network that is internationally distributed and you may not be able to keep state across all of them alright then let's take a question from our viewers in the internet

the signal angel please binary strike asks with regards to TLS 1.3 in the enterprise shouldn't we move away from perimeter interception devices towards putting the controls on the endpoint like you would have a zero trust

so in my opinion yes but there are many people in the enterprise security industry who think that this is not feasible but I mean discussion about network design that would be a whole other talk

alright then let's take a question from mic 4 please yeah it's also related to the enterprise TLS the browser can connect to an enterprise TLS server without any problems yeah so it's built that it's compatible with the existing TLS protocol

thanks and the reason like whether you can avoid that or not that's really a more complicated discussion that would kind of be a whole sub talk so I cannot answer this in a minute but come to me later if you're interested in details alright then let's take another question from the interwebs

we have one more question from IRC would you recommend inserting both as well? you said you had a choice to train interwebs I mean that's what I said what is done that's actually what browsers are doing and I think this is a good idea

I just think that this only covers a small fraction of these deployment issues ok we still have plenty of time so let's go to mic 2 please yeah as you said we have still a lot of dirty workarounds concerning TLS 1.3 and all the implementations in the browsers and so on

is there a way to make like a requirement for the TLS 1.3 or 1.4 compliance to meet some compliance to the standard so you have like a test you can perform a self test or something like that

and if you pass that you are allowed to use the TLS 1.3 logo or 1.4 logo you can do that in theory the problem is you don't really want to have a certification regime

that people like have to ask for a logo to be able to be allowed to implement TLS and that's kind of one of the downsides of the open architecture of the internet we allow everyone to put devices on the internet so we kind of have to live with that and there's no TLS police so we kind of have no way of preventing people to use broken TLS implementations

and I mean people won't care if they have a logo for it or not alright let's go to mic 5 all the way in the back there I have a question about Shor's algorithm and TLS 1.3

because since quantum computing is getting very popular lately and there are a lot of improvements in the industries so what's the current situation regarding TLS 1.3 and all those quantum based algorithms that break the complexity into polynomial times

there's no major change here so with TLS 1.3 you still are using algorithms that can be broken with quantum computers if you have a quantum computer which currently you don't but you may have in the future there is work done on standardizing future algorithms that are safe from quantum attacks

but that's kind of in an early stage and there was an experiment by Google to introduce a quantum safe handshake but they only ran it for a few months but I think we will see extensions within the next few years that will introduce quantum safe algorithms but right now there's no change from TLS 1.2 to 1.3

both can be attacked with quantum computers okay so I think we are getting to our last or second to last question so let's go to mic 3 I think you've been waiting the longest okay in older versions of TLS there was a problem for smaller devices such as IOT and industrial devices

has there been a change in 1.3 to allow them to participate? I mean I'm not sure what entirely you mean with the problem I mean of course TLS needs some the performance issues of TLS have usually been overstated

so even in a relatively low powered device you can implement the crypto I mean the whole protocol is relatively complex and you need to implement it somehow but I don't think that's such a big issue anymore because even IOT devices have relatively powerful processes

these days. Okay, all right, that concludes our Q&A. Unfortunately, we are out of time, so please give a huge round of applause for this great talk. Thank you very much.