 It's a pleasure to introduce Hanno Becht to you. He's no stranger to the chaos crowd. He's been to several Easter Hacks and at 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 Hanno. Hello. Yeah. Okay. Hello. Today I would like to talk about a new revision of TLS. TLS is the Transpillers Security Protocol, where I hope that everyone knows. It's a protocol that we can set up on other protocols. And there is an authenticated and enclosed channel for a very secure Internet. And we have a new version since August, TLS 1.3. And first of all, I would like to talk about the story. Why did we have this new version? How did we get there? And what were the design decisions for this protocol? Yeah. The very first version of SSL was... That's what I hear about you. Which is still very similar to TLS 1.2, which we use very often these days. Then in 1999, it was handed over from Netscape to ITF, to the Internet Standards Organization. And they named it TLS. So that's the story of the versions. First of all, the SSL, I marked red here, because these two versions are broken. You can't really use them. You can't find a safe way to use them, just from the design of the protocol. Then in 1999, we named it TLS. And TLS is still okay if you do everything right, but it's still... It's not completely broken, but you should avoid it. TLS 1.2 is the one you use the most these days, and TLS 1.3 is the new version. And what you can see is that the biggest step is between 1.2 and 1.3. It took a long time for there to be no new developments. Okay. You've probably heard that TLS has a lot of similarities. And nowadays, a good similarity has a logo and a nice name. And I'd like to go into one similarity, a safe way. I was very surprised when I realized that there are these so-called padding oracles that appear in the CPC-mode. So, that's usually used automatically for the actual data, for the symmetric integration of the actual data. The thing is that when we integrate things, what we normally use are block numbers. So, block connections, so to speak. And they always integrate a certain data set, a certain amount of data, normally 16 bytes. And this CPC-mode was the standard mode in previous TLS-mode versions to connect. That's what it looks like. We have a start vector, IV, an initiation vector. And then we connect a block to data, and we export this connection to the next plain text that should be connected. So, the ciphertext is used, so to speak. And because the blocks are from data and our data can't always be in 16 bytes, it could also be 5 bytes blocks, we have to fill up this empty space. And for that we need a kind of padding. And in TLS, first we had data, and then we added a Mac. So, that's, so to speak, a value that the authenticity of the data has achieved. And that's what we solved. And this sequence of lines has been very difficult, because this padding is, if we have to fill up one byte, then we fill it up with 0, if we have to fill up two bytes, we fill it up with 1, if we have to fill up three bytes with 2, and so on. That's pretty easy to understand. Now, let's assume for a moment, we have a situation where an attacker can manipulate data and can also see if the server gets bad or bad padding or if he simply gets bad data and sleeps a lot for this Mac procedure. And that's the conclusion of the middle mode in the CPC mode. And what an attacker can do here is that the very first thing an attacker does is just throw a block away at the end. He simply blocks the transfer of the last block. And then, what we want to assume is that the attacker wants to have the last byte solved, because that could contain very interesting data. So what he can do is, he can manipulate the byte in the ciphertext with a, so what is it supposed to do? And a byte is just 256 bits, so a byte can be 256 bits, so he just has to guess enough often and then use this value to XOR. And what you can imagine now is that if we get XOR out of the back zero, then we can see that the padding is correct. If we get some garbage out of here, then we know that the padding was a mess. So if you just guess enough often enough, you can create a single byte here under the assumption that he will find out if the padding is correct or not. So he could create a byte. But he can also go on and say, we have already solved this one byte, then he can also go on to the next byte. So we XOR the right byte with the guessed byte from the first one, where we already know what it is. And XOR also the next byte in there. And if that is 1-1, then we know that we have a correct padding. So that's how the attacker recognizes the next byte. He knows that for all other bytes. In 2002, the padding oracles were found theoretically. TLS has different error messages, like if the padding is wrong, if the padding is wrong, we get the Sf wrong error. And if the mac was wrong, we get bad record mac error. The attacker can usually not see the TLS error. But if he could see it, he could use it as a padding oracle. Because they are solved, it is not a practical attack. In 2003, it became more practical with timing attacks. And this allowed practical decryption of TLS traffic. A little bit more practical decryption. This was fixed or kind of fixed. In later versions of TLS, it was fixed, so to speak. Directly here from the standard text, we have a little timing channel in the mac performance. If you read something like that, it sounds maybe... It depends on how large the data fragment is, but it should not be large enough to be exploitable. In 2013, we found lucky 13 attack that it is actually large enough to be exploitable. The designers of the standard belief 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. Theoretically, it is possible to implement TLS so that the CBC timing attack is safe, but it adds a lot of complexity to the code. We will see that later. Then there was another padding oracle, which was called Poodle, which... In 2014, we will see another padding oracle. That we call Poodle. The protocol was built in a way that you could not avoid this padding oracle. Directly in SSLv3, it was built into the design. That means you can't work around it. The reason here was... We find the same mistake in TLS again. And TLSv1 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. And then TLS implementations, which should have used fixed paddings, but which simply did not check. And that makes TLS sensitive for Poodle. One of the people who found the Lucky 13 attack looked at implementations and saw it. One person who found the Lucky 13 attack found the Lucky Microseconds in 2015. In the SSL library of Amazon, S2N. And they had still a timing. And they also proved that the countermeasures of Amazon do not work against Lucky 13. 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 export. In fact, they tried to fix it in OpenSSL, and another bug was added that made a new padding oracle possible. The simpler one as Lucky 13 is the Lucky Minus 20. Yes. As I said, the original attacks do not work, because the TLS errors are solved. But what if there are implementations that produce other errors that can be seen? For example, TCP errors, which can be used to set connections or timeouts. And of course, we find that in the free, wild-band implementation. Then I want to look at another attack, which is... Let's look at the other attacks, the so-called Bleichenbacher attacks, to establish a shared key. That was published by Daniel Bleichenbacher in 1998. If we look at the RSA connections, we have to prepare a little bit in the RSA connection. And the Pkcs1.5 standard. It starts with 002, random data as padding. Two zeros that mark the end of the padding. 003 stands for TLS1.2. Totally obvious, wasn't it? And then we have the data we want to hide. The point is now, that we know that a connected block has to start with 002. What if that's not the case? It decrypts some data from the client. And then it doesn't start with 002. 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. We will tell the attacker something. That is, the decrypted data can't start with 002. And we realize, it's enough to send modified ciphertexts and get enough to decrypt the data. I didn't want to put the formulas on the slides for that. In TLS1.0 there were some countermeasures. The basic idea was that if you decrypt something, and that's wrong, then you should replace it with a random value and this random value as a secret key. And just do it as if nothing had happened. And then just keep going. And the handshake will be a failure, because you don't have the same key. That keeps the attacker from finding out whether the data is correct or not. In 2003, a research team found out that these countermeasures were incomprehensible and it's still not completely clear how it should be implemented, because there was this version problem and it wasn't exactly written what to do, even if only the version is wrong. So it was still possible to create an attack that, despite these countermeasures, still worked. In 2014, there was a paper that said that Java was still available to these same-bacher attacks, because there was still this decoding, this connection. And then an exception was thrown from Java and the exception is long enough that you could make a timing error. But now it wasn't really practical to use at that time. In 2016, there was the so-called Drown Attack, the Drown Attack. And that was a same-bacher attack in SSL Version 2. And now we could ask ourselves, okay, SSL is this super-old version from 1985 or whatever it is. But you could still use the data from a current TLS version. And if a server is still available, this old version is still supported. And that's why it's still relevant. That's the Drown Attack. And yes, I wanted to find out if there is still a server that is still available to these same-bacher attacks. So I wrote a little story about what it scanned. The first thing I found out was that Facebook was available and from the top 100 pages in the Alexa ranking there were still a third of the websites available. And at least 15 different implementations were available out there. So yes, that's what it was. And about a month ago, there was a newspaper that said that you could use cache side-channel attacks that are particularly relevant to cloud infrastructures for different servers. You can still use that to use these same-bacher attacks. And now I want to show you that you can't read it because it's way too small, but these are the articles, the sections that show in the different TLS versions the countermeasures against the different same-bacher attacks. And yes, they start with a small section of what you should use as a countermeasure and then they add more and then again in TLS 1 and 2. So what you can clearly see is that it's getting more and more complicated to protect yourself from these attacks. And yes, with each new TLS version more complexity was introduced to prevent these same-bacher attacks. And yes, that was only two examples. There were even a lot more attacks on TLS 1.2 and also older versions against bad caches. And the handshakes were also attacked. Sweet32 has attacked block ciphers that have small block sizes. Triple handshake is a pretty complicated interaction of different handshakes. And yes, the current, the general trend was that in TLS 1.2 and earlier and older if there was a mistake, there was a closure then the people just said, yes, we have to find a workaround for this security problem. And if the workaround doesn't work, well, if it doesn't work, then we just need more of it. We do new, secure methods, but the people are looking for it. So the old ones are still active. And the people can choose to use a slightly older and safer method. What has led to it that most of the time the unsafe methods have been used, because yes, there were there were methods that didn't have these weaknesses, but they were optional. And TLS 1.2. And I think that's the important the important changes that came with TLS 1.3. So the way of thinking has changed. The people said, okay, if there are some misunderstandings and we have something better, then we should remove the old that with the misunderstandings, the problematic one. And that was one of the main changes in TLS 1.3. So there were a lot of things that were simply removed. This CPC modus, for example, or RC4, also a different problematic Cypher. We also have Triple Desk, that's the one with the small block sizes. We still use GCM, but no longer with explicit nonces, so with explicit numbers, so to speak. We have RSA, a completely removed and only for signatures and hash functions, which have proven to be unsafe. Diffie-Helmen with adapted parameters or with small parameters were also removed, because they were also problematic. And also Electric Curves were removed, which did not appear so safe. And what also came some researchers, such as TLS, looked at a scientific path. They tried to analyze the format and also whether the various security features of the protocol could be improved. And many of the connections that I introduced before were found by these researchers and who analyzed it. But these analyzes also included TLS 1.3 to make a more robust protocol more robust against attacks. And this is also a great progress. There was a much, much better cooperation between scientists who looked at the program, the protocol and the people who wrote the protocol. But you could now say, okay, security is quite nice, but what we really, really need is speed. So what at least some people are particularly interested in. We want our Internet to be fast. We want our browser to be able to load the page immediately when we open it. And TLS 1.3 also introduced speed improvements. And I once presented a diagram for the handshake and it's pretty simple. So I just introduced the most important things that support my point. But if you look to the left how an old TLS handshake works, then it starts with this little tell-all and with which version and which encryption methods the client supports. The server answers which encryption methods it wants to use. And then the key exchange takes place and then the client sends his part from the key exchange, so from the key exchange exchange and a closing message. And then the server sends a closing message and then in TLS 1.3 it was a bit compromised. The client sends a key exchange, a closing message with his hello, his welcome, his connection start message. And the server answers the server hello, the closing message of the client and also with a closing message. And that leads to the client able to exchange data immediately. That's the situation for a voice handshake, a handshake that has no communication before. You just have to go in and out and then you can transfer data. And in the previous version you had to go in and out at least twice. So you can go much faster to transfer data. Okay, so we took out a roundtrip from this handshake. There are also security improvements in this handshake. So more security and more speed. And especially what we have is more security when we build up a existing connection again. So when we use a key in the previous connection. We can also protect more data. For example, when an attacker is playing around with the handshake. There are more theoretical attacks but we can also prevent them better. Okay, so Theles has a better and faster handshake. And if you want to know more details about this handshake then there was a talk in this congress two years ago that shows much more details. I can only recommend it to you. The link is here on the slides and the slides are online. There is also something called the zero roundtrip handshake. And that is even faster. We can send data immediately. How can we do that? Actually, we trickle a bit because we need a previous connection of the key we already have. And from this key we can generate a new key with which we can send data immediately. What we need is this pre-shared key a pre-shared key from a previous connection. And then we can send data without any delay. That's cool, right? But this zero roundtrip mode is not free of charge. There is a problem here so-called replay attack. That means an attacker can record the data we send and then send it again. And the server thinks well I'll just do twice what this request should do. There is a certain danger with this zero roundtrip handshake. And the standard also says it is important that you only use it when you have a profile how to use such a zero roundtrip handshake. Let's look at the HTTPS that is the protocol with which we will use it most often. If you look at the HTTPS then the standard says that a GET request should be idempotent. A POST request must not be fulfilled. What does this idempotent mean? That means that if you send the same request twice then the same answer should come. In theory you can say GET requests are idempotent that they are safe for zero roundtrip handshakes. The question is do web developers know what idempotent means? I have asked web developers if they know what it is and the answer is very bad. In an ideal situation where web developers know what HTTPS is, then you can use these zero roundtrip handshakes. Zero RTT doesn't have strong pre-safety. That means if this pre-safety is compromised then it means that the content of my connection can be laid open. It looks a bit problematic and many speculate that the attacks we see on HTTPS 1.3 will focus on this zero roundtrip handshake because it is one of the most fragile parts of the standard. But there is speed so we use it. The good news is that it is completely optional and we don't have to use it because we think it is problematic and if too many attacks take place that need these zero roundtrip handshakes then we turn it off and can use HTTPS 1.3 just not that fast. How do we deploy it now? We have a wonderful new protocol. We don't just have to secure it, not just fast. We also have to bring it into the world. And on the internet. To the real one. And not the theoretical internet where there are no bugs where everyone knows how protocol works but the real one with the internet of things devices and such devices. That starts with the version number. It may sound like a triviality but a new version of TLS 1.3 is the new version number for the protocol version that we see here on the red files. It is shown in a TLS 1.3 handshake. And there you can see different version numbers. On top you can see TLS 1.0 encoded as 0301 and later TLS 1.2 with 0303. That looks all the same. And then if you scroll further down you can see we still have under extension supported versions TLS 1.3 encoded as 0304. What just happens? That looks all the same. The first thing we have to see is that we can't encode TLS as a version 1 because it came after SSL 3. That means we will encode TLS 1 as version 3.1 and encode with 3.2, 3.3 and for 1.3 it will only be complicated. The first version that you saw in the white shark is from the so called TLS record layer. We can put it in for compatibility. It is a protocol in the protocol but it doesn't really matter. If we have a new TLS version we can't just tell everyone let's use all these new TLS versions tomorrow. So we have to be able to deploy them and still be compatible with the old versions. So let's assume we have a small TLS 1.2 but a TLS 1.0 server. There is a very complicated mechanism for that. TLS 1.2 is connected and says hey I speak TLS 1.2 the server says I don't know but the highest I can is TLS 1.0 and sends it back. If the client can still TLS 1.0 they can connect. That's pretty easy. Let me illustrate with this code to make it wrong. But we are talking about the real internet. And on the right internet there is business business solution. So very expensive and terribly bugged. So websites with Firewalls from Cisco or IBM Domino servers and there we get a business version but this conversation. The client server says I can't make a mistake. It's always the first 10 years old in the business world, very young. We call this intolerance that always happens when a new TLS version is introduced. Every time we introduced a new device that needs a new version then it simply doesn't work. Browsers have to somehow deal with it. The problem is when a TLS version brings a new version and nothing works then the user uses the browser and the user doesn't use the browser anymore. Browsers have to deal with it and what the browser is doing now is we try with the latest TLS version and if we get a mistake then we try a lower version and a lower version and somehow the connection works. We have a browser and a business server that supports version 1.0 and after 3 tries we have a connection. Now you can remember Poodle. I mentioned Oracle in version 3 that was discovered in 2014 You may be wondering SSL version 3 from 1996 pretty old who uses it in 2014? For 16 years you shouldn't use it anymore who uses it? For example Windows 7 used it that was never updated but ok normal browser and server should at least use TLS 1.0 maybe not 1.2 but at least 1.0 but we have this browser that tries to build a new connection when you find a mistake and what its attacker can do is to attack version 3 because it can block connection with a new TLS version which means it forces the little ones to do a downgrade on SSL 3.0 and then it can attack the gaps in SSL 3.0 Ok so the downgrades try to solve security problems we have to build a new workaround called SCSV a way for the server to say that it doesn't support this version implemented is a special encryption method with which the server can say to the client that he shouldn't do downgrades we had this workaround for broken server and need a workaround for security issues but at some point the business products corrected their mistakes and stopped and the browser could stop doing downgrades so they didn't solve it they solved it for version 1.2 but not for future versions so with TLS 1.3 we have the new version intolerance and we would break everything and the new security wouldn't help us much when the TLS working group realized that it overworked the handshake and in a way that the old version still remains with version 1.2 and a new extension that supports new TLS versions for example TLS 1.3 and also for future versions you probably wonder after the whole story we will have the same intolerance again and the server will make a mistake when they see a new version and to address this David Benjamin from Google made a proposal to improve the future compatibility and improved the grease mechanism this grease mechanism says that unknown versions in the list of supported TLS versions should be ignored and can connect with one of the supported versions and somehow we have to get the server to implement it and the idea is that with grease too many versions that don't exist yet that will never be used in real TLS versions in these versions so we can make sure that if the server really implement this function if he really ignores the values that he will then support future TLS versions meaningfully the hope is that when this business with its broken versions negotiations will be noticed before they bring their product to the market when a new TLS version will be around well we don't have any downgrades anymore we have the grease mechanism we can finally bring TLS 1.3 around but then there was this middle box problem in summer 2017 sorry this is the wrong year it should be 2016 sorry in summer 2016 TLS 1.3 was almost finished but then it took almost another year I'm sorry I made it completely apart 2017 was right and TLS was almost finished in 2018 until it was really finished and the reason for this was that browser manufacturers implemented a TLS 1.3 version and found a lot of connection errors and the reason for this was that there were devices that wanted to analyze the data traffic and they recognized that we don't know a TLS package that doesn't look like it normally so let's just throw it away that's just a weird TLS package let's just throw it away that was passive medium passive not active people who have done a manual attack but a router or what sits on the network and what data traffic looks like like a normal TLS package and then the browser manufacturers made a fix so that TLS 1.3 looks more like TLS 1.2 and the important thing was that they just introduced some old TLS 1.2 that should be changed so one of them is the change type aspect so the change method that was in TLS 1.2 and there was a signal that everything should be connected from now on and the idea was if we just send a meaningless CCS message then these devices might think that they can't connect and that's why they won't analyze and it actually worked that's why the connection errors were massively reduced so there were a few other things and at some point the errors were small enough that the browser manufacturers thought ok now we can use it but there were still a few errors that's for example a PIXMA printer from Canon they also built a HTTPS server with network support and we have to talk about the NSA when we remember the Snowden Affair one of the things that came out was that there was an accident generator called the dual ECD-RGB so an accident generator and it has a rear door a back door and most people believe that it's a rear door from the NSA so you can predict which accident numbers this accident generator will give and what was also in the Snowden was that the NSA gave 10 million dollars to the NSA security institute to implement this accident generator and there was a proposal for a TLS extension which is called Extended Random so it has an accident and they just called it an accident number why? there was no reason we could just do it it was just a proposal everyone can make proposals for new designs it was finished but then it was out there and in 2014 some researchers looked at this dual ECD and if you look at this Extended Random this extended addition then it's much easier to use this rear door in the accident generator and the NSA B-Safe also supported this extension but it was switched off and switched off when the F5 was on and there was no real implementation that really used it so there was no problem with this extension and they used the NSA B-Safe Bibliotheque and this extension activated the new design and because this extension only had a design it didn't have an official extension every extension had an official number so the server could see which extension it is but in the implementation they simply used and this is a collision with one of the obligatory extensions that made the TLS 1.3 so these can't support this new extension so they have this Extended Random and that wasn't it and then there was connection and in the TLS protocol they simply gave this extension a new number and then it didn't work and and there were many more such errors and also in the youngest past Java, which is also spread in the environment they now have TLS 1.3 support but that doesn't work so there are many errors What about future TLS versions? We have grease that helps us a bit it helps us with the versions but it doesn't help with such a complicated middle box problem there was the message from David Benjamin from Google that we simply a new TLS version that should only be used for a few months roll out and then deprecate so that the internet doesn't get used to it that there are new protocols and this deployment would be more difficult but enterprise security for instance if you go to business security conferences then you realize enterprise security people are interested in artificial intelligence so for example they want to use machine learning to recognize bad things for example you find that they want to use machine learning to recognize bad TLS traffic because the key is we can't recognize if the mail wire is in it so let's let us learn the machine so we would rather expect that in the future with increased machine learning TLS versions, number, change which will be even more difficult to fix one of the points at TLS was that it removed the early TLS solution handshake there is no probability secrecy and it is still harmful for the Bleichenbacher attacks I quote from a mail from the Bank Industry I have recently learned that there is a suggestion that many of our institutions would consider namely the RSA Key Exchange to deprecate that will create significant problems for banks that use all TLS internal and have significant security relevant in the TLS description and in Clartex it should mean that they treat each new connection with a new key according to the old protocol with the RSA the answer from Kenny Patterson from the group says no, we don't do it, we want a safer internet you are a little late for the party we are talking with the Forester from Ashenberg to learn to clean empty cans we are actually exactly the same with version 15 and the RSA Key Transport has already flown out 12 times the banks are usually pretty slow but that is already crazy there were a few versions a few suggestions to save it but they were rejected and the previous opinion with TLS is that the traffic should not be observed so we don't want to make anything easier on monitoring so the industry went to the ETSI and created a business enterprise TLS that allows these solutions the IETF was not particularly happy that the name TLS was misused there and the ETSI is still called ETSI TLS 1.3 is done starts to use everything your browser can probably do it too so in summary, what does TLS do TLS 1.3 behaves louder and safer is faster and new things on the internet deploy is chaos and we have time for questions as Hanna said we have about 6 minutes for questions we have 5 microphones in the hall so if you want to ask a question then come to the microphone and please ask a short clear question so we can question as many as possible thank you very much for the interesting talk is there a possibility to prevent the use of enterprise TLS yes there is the main idea is to use the state DeFiHammer exchange and if you see that it happens twice some servers use it for optimization, so it's not very safe there are longer discussions I can't answer that I can't understand it but there are options before we go to the next question please leave room to all people please do it as quietly as possible so we can finish the question session microphone 2 please hi I I was asked about the replay why is there nothing like sequence numbers there is something but the problem is if there are several TLS termination points then it's difficult to keep all the same state good a question from the internet please binary strike asks at TLS 1.3 in business environment shouldn't we take the step to get away from TLS on the firewall and instead do it on the endpoints in my opinion yes but there are a lot of people in the business world who don't decide for realists but discussions about network design belong to a completely different talk good question from the microphone please the question also to enterprise business TLS the a browser can connect to an enterprise TLS without problems yes it is so built that it is compatible and whether you can avoid can also be your own but talk to me later good a question from the internet please a question from the IRC would you recommend to include strange values in handshakes to train the implementers that's exactly what browsers do, that's exactly what I said but that only covers a small part of this deployment problems good we still have time, micro 2 please as you said we still have a lot of dirty flickering and work around around TLS 1.3 the browser implementations there is a possibility an requirement for TLS 1.3 or 1.4 to do that implementations really hold to this standard that there is a test or a self-certification that you have to to use the TLS 1.3 or 1.4 logo in theory you can do that but we actually don't want to introduce a certification regime where people ask for such a logo and an permission one of the big problems with the open architecture of the internet so we have to live with it there is no TLS police in particular so we don't have a way to take care of people using broken TLS implementations micro 5 please I have a question about source algorithm and TLS 1.3 because since quantum computing always becomes more current what is the current situation about TLS 1.3 and quantum-based algorithms with which you can break up solutions there is no greater change TLS 1.3 uses further algorithms that can be broken with quantum computers there is already early practice to use post-quantum algorithms to counter TLS but it is early practice I think in the next few years we will see such developments but there is 1.2 to 1.3 not yet last or second question micro 3 please in all TLS versions there was a problem for small devices with little power in TLS 1.3 there was an improvement that enables these devices to participate the performance issues of TLS the performance problems have been generally overpowered also on a very smooth device you can implement real crypto but I don't think such a big issue anymore because even IoT devices even Internet of Things devices can have enough powerful processors to be able to do that that ends our Q&A we have no more time please a big applause for Hanno