The Rocky Road to TLS 1.3 and better Internet Encryption

Video thumbnail (Frame 0) Video thumbnail (Frame 1192) Video thumbnail (Frame 2410) Video thumbnail (Frame 6061) Video thumbnail (Frame 7454) Video thumbnail (Frame 8651) Video thumbnail (Frame 11810) Video thumbnail (Frame 19117) Video thumbnail (Frame 21360) Video thumbnail (Frame 34114) Video thumbnail (Frame 36357) Video thumbnail (Frame 37890) Video thumbnail (Frame 44694) Video thumbnail (Frame 47095) Video thumbnail (Frame 48762) Video thumbnail (Frame 50485) Video thumbnail (Frame 51750) Video thumbnail (Frame 53012) Video thumbnail (Frame 55116) Video thumbnail (Frame 57208) Video thumbnail (Frame 64952) Video thumbnail (Frame 66273) Video thumbnail (Frame 70214) Video thumbnail (Frame 72134) Video thumbnail (Frame 73737) Video thumbnail (Frame 75135) Video thumbnail (Frame 76528) Video thumbnail (Frame 79371) Video thumbnail (Frame 80970) Video thumbnail (Frame 82231) Video thumbnail (Frame 83967) Video thumbnail (Frame 86810) Video thumbnail (Frame 88675) Video thumbnail (Frame 90109)
Video in TIB AV-Portal: The Rocky Road to TLS 1.3 and better Internet Encryption

Formal Metadata

Title
The Rocky Road to TLS 1.3 and better Internet Encryption
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
Since a few months we have a new version of TLS, the most important encryption protocol on the Internet. From the vulnerabilities that created the need of a new TLS version to the challenges of deploying it due to broken devices this talk will give an overview of the new TLS 1.3.
Keywords Security

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Hexagon Transport Layer Security Chaos (cosmogony) Encryption Musical ensemble Flow separation Event horizon
Transport Layer Security Transport Layer Security Musical ensemble Communications protocol
Asynchronous Transfer Mode Multiplication sign Transport Layer Security Mereology Revision control Advanced Encryption Standard Goodness of fit Latent heat Internetworking Vector space Encryption Spacetime Symmetric matrix Vulnerability (computing) Oracle Graphics tablet Authentication Standard deviation Block (periodic table) Software developer Transport Layer Security Variable (mathematics) Cryptography Vector space Revision control Self-organization Encryption Block (periodic table) Communications protocol Oracle Asynchronous Transfer Mode Spacetime
Graphics tablet Server (computing) Matching (graph theory) Block (periodic table) Moment (mathematics) Cryptography Data transmission Blockchiffre Exclusive or Order (biology) Motion blur Encryption Block (periodic table) Error message Oracle Asynchronous Transfer Mode Condition number
Complex (psychology) Random number Implementation Server (computing) Transport Layer Security Multiplication sign Real number Dreizehn Client (computing) Code Side channel attack Theory Number Revision control Mathematics Different (Kate Ryan album) Error message RSA (algorithm) Graphics tablet Time zone Standard deviation Key (cryptography) Block (periodic table) Kolmogorov complexity Server (computing) Transport Layer Security Multilateration Cryptography Public-key cryptography Connected space Code Error message Block (periodic table) Bounded variation Communications protocol Oracle RSA (algorithm) Library (computing) Row (database) Spacetime
Axiom of choice Complex (psychology) Randomization Java applet View (database) Multiplication sign Curve 1 (number) Ellipse Open set Parameter (computer programming) Client (computing) Mereology Software bug Mathematics Web service Cryptography Roundness (object) Different (Kate Ryan album) Data Encryption Standard Encryption PLS (file format) Information security Vulnerability (computing) Exception handling Area Collaborationism Algorithm Block (periodic table) Ciphertext Web page Transport Layer Security Parameter (computer programming) Bit Cloud computing Schlüsselverteilung Measurement Electronic signature Connected space Category of being Message passing Hash function Buffer solution Right angle Information security Asynchronous Transfer Mode Web page Point (geometry) Asynchronous Transfer Mode Server (computing) Implementation Transport Layer Security Mathematical analysis Web browser Revision control Cache (computing) Internetworking Well-formed formula Computer hardware Percolation theory Communications protocol RSA (algorithm) Robot Time zone Axiom of choice Information Java applet Interactive television Mathematical analysis Cryptography Elliptic curve Error message Speech synthesis Formal verification Communications protocol Oracle Computer-assisted translation RSA (algorithm)
Rounding Slide rule Roundness (object) Type theory Link (knot theory) Key (cryptography) Transport Layer Security Sheaf (mathematics) Right angle Information security Connected space
Mereology Software bug User profile Type theory Different (Kate Ryan album) Core dump Row (database) Extension (kinesiology) Information security Enterprise architecture Transport Layer Security Bit Connected space Type theory Arithmetic mean Internetworking Content (media) Encryption Information security Asynchronous Transfer Mode Data compression Point (geometry) Asynchronous Transfer Mode Random number Server (computing) Idempotent Software developer Firewall (computing) Real number Transport Layer Security Theory Number Revision control Internetworking Communications protocol Data type Standard deviation Multiplication Key (cryptography) Suite (music) Length Theory Client (computing) Line (geometry) Group action Web-Designer Personal digital assistant Revision control Fiber bundle Musical ensemble Communications protocol Extension (kinesiology)
Server (computing) Server (computing) Transport Layer Security Transport Layer Security Client (computing) Client (computing) Code Number Connected space Revision control Mechanism design Web service Internetworking Personal digital assistant Revision control OSI model Communications protocol Communications protocol Row (database)
Web page Enterprise architecture Server (computing) Enterprise architecture Firewall (computing) Maxima and minima Client (computing) Product (business) Product (business) Revision control Web 2.0 Internetworking Internetworking Personal digital assistant Right angle
Enterprise architecture Server (computing) Enterprise architecture Transport Layer Security Multiplication sign Transport Layer Security Client (computing) Web browser Semiconductor memory Web browser Revision control Crash (computing) Revision control Error message
Graphics tablet Server (computing) Server (computing) Transport Layer Security Transport Layer Security Control flow Web browser Web browser Windows Mobile Connected space Revision control Process (computing) Internetworking Normal (geometry) Error message Window
Point (geometry) Suite (music) Random number Server (computing) Group action Randomization Enterprise architecture Transport Layer Security Client (computing) Web browser Drop (liquid) Plastikkarte Product (business) Revision control Web service Mathematics Mechanism design Internetworking Encryption Cuboid Extension (kinesiology) Router (computing) Message passing Information security Error message Enterprise architecture Server (computing) Transport Layer Security Electronic mailing list Client (computing) Exploit (computer security) Web browser Product (business) Connected space Mechanism design Mathematics Message passing Process (computing) Googol Content (media) Order (biology) Revision control Normal (geometry) Freeware Extension (kinesiology)
Point (geometry) Random number Server (computing) Implementation Random number generation Divisor Transport Layer Security Web browser Canonical ensemble Function (mathematics) Number Duality (mathematics) Mathematics Bit rate Encryption Extension (kinesiology) Local ring Information security Library (computing) Default (computer science) Theory of relativity Key (cryptography) Server (computing) Transport Layer Security Web browser Connected space Number Message passing Software Vector space Duality (mathematics) Right angle Encryption Information security Backdoor (computing) Communications protocol RSA (algorithm) Library (computing) Extension (kinesiology)
Predictability Enterprise architecture Java applet Transport Layer Security Bit Connected space Revision control Mechanism design Googol Integrated development environment Prediction Internetworking Revision control Cuboid Information security Communications protocol
Enterprise architecture Algorithm Electric generator Transport Layer Security Virtual machine Twitter Mathematics Machine learning Integrated development environment Blog Speech synthesis Encryption Information security Information security RSA (algorithm)
Email Group action Transport Layer Security Transport Layer Security Schlüsselverteilung Cryptography Connected space Mathematics Causality Musical ensemble Self-organization Encryption Information security Information security RSA (algorithm) Self-organization
Key (cryptography) Transport Layer Security View (database) Transport Layer Security Bit Cryptography Connected space CAN bus CAN bus Internetworking Encryption RSA (algorithm) Self-organization
Point (geometry) Addition Enterprise architecture Asynchronous Transfer Mode Standard deviation Group action Enterprise architecture Transport Layer Security Constructor (object-oriented programming) Multitier architecture Transport Layer Security Web browser Cryptography Connected space Local Group Content (media) Digital rights management Content (media) Internetworking Self-organization Encryption Musical ensemble Asynchronous Transfer Mode Self-organization
Fluid statics Enterprise architecture Web service Computer configuration Schlüsselverteilung Mathematical optimization
Point (geometry) Content delivery network Noise (electronics) Multiplication State of matter Transport Layer Security Sequence Number Radical (chemistry) Software Internetworking File viewer Musical ensemble
Enterprise architecture Software Transport Layer Security Web browser Information security Communications protocol
Point (geometry) Standard deviation Implementation Multiplication sign Transport Layer Security Web browser Public key certificate Theory Fraction (mathematics) Internetworking Right angle Software testing Computer architecture
Complex (psychology) Polynomial Algorithm Mathematics Googol Multiplication sign View (database) Source code Quantum Control flow Quantum computer Extension (kinesiology)
Revision control Point (geometry) Mathematics Process (computing) Transport Layer Security Cryptography Communications protocol
Roundness (object) Multiplication sign Infinite conjugacy class property Cartesian closed category Musical ensemble Semiconductor memory
[Music] all right now it's my very big pleasure to introduce Hanna back to our you he's no stranger to the chaos crowd he's been through several Easter hex 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 gonna look like please give a huge applause and welcome hello
yeah [Music]
[Music] [Music] so the very first ssl which 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 taking over from Netscape 2 the IETF which was 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 Werner abilities that are part of the protocol then we had in 1999 worst yet renamed to TLS and TLS is kind of still kind of ok 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 years 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 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 ok you've probably heard that we had plenty of vulnerabilities in TLS around yes and also these days good variability always has a logo and a nice name and I want to go into one vulnerability which doesn't have a look not one of the variants I'm I was very surprised when I realized that but that so-called padding oracles they are in CBC mode which is encryption we use for the actual data encryption the symmetric data encryption so and the thing is when we encrypt data what we usually use our 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 encrypting into the next plaintext and encrypted 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 the correctness of the data the authentication of the data and then we Pat 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 it if we have one by to fill up we make a zero zero if we have two bytes to fill up will you make one one three bytes two two two two two three 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 match 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 it throws one block away at the end it just blocks the transmission of that block and then it changes something here so what we assume here is the attacker wants to know this decrypted bytes because it may contain some interesting data so what he can do is he can manipulate this byte with the guess and by this only 256 waves of various the byte can have so he can guess enough times and exhaust it with this value and if you think about it we XOR it 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 learned somehow whether the padding is valid or not so he could decrypt one byte but he can go on let's assume we we learned that one byte we have decrypted it and then we can go on with the next byte so we XOR this byte on the right with with the guests we are with what we already know that it is and with the one and then we XOR this next byte with our guests and also a one and if this ends up being 1 1 then again we have a valid padding so the attacker learnt the next byte and he can do this for other bytes this this was originally discovered in 2002 by Sergey moodini but it was kind of only theoretical so one thing here is that TLS has these error messages and this there are
different kinds of errors and if you read up in the TLS 1.0 standard if there's a if the padding is wrong then you get this decryption failed error and if the Mac is wrong so the data has a 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 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 but and it is in theory possible to to implement TLS in a way that is safe from this timing attacks but it adds a lot of complexity this to the coach 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 pending Oracle which was called portal which was in the old version SSL 3 and this was kind of by design so the the protocol was built in a way that you could not allow to 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 specific value were in the past it could have any value and turned out they were CLS 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 the one of the people who who has found the lucky 13 attack he looked at implementations and so as they have fixed lucky 13 properly and they looked at an s 2 n which is a a 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 back open SSL which was kind of funny because when Optimus I'll try 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 Oracle's but if you remember back what I said for the very 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 consented TCP error or just cut the connection or have any kind of different behavior because the whole attacker 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 Oracle is still an issue then I want to look at another tank which is a so-called black in Baja attacks and they tragedy of RSA encryption and that is kind of the asymmetric encryption which were used at the beginning of a connection to establish a shared key this attack was found in 99 by Daniel Blankenburg and if you look at
the RSA encryption before we encrypt something with RSA oh we do some preparations and the way this is done and in OTS versions is the so-called pkcs1 1.5 standard and how this looks is it starts with the 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 version number 0 3 or 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 now the but the relevant thing for this attack is mostly the 0 0 0 2 at the beginning so we know each correct and encrypted block if we decrypt it it starts with 0 0 0 2 so we may wonder if we implement the TLS server and it decrypt some data from the client and then it doesn't start with 0 0 0 2 what shall I do and the naive thing would be yeah of course we just send an error message because something is obviously wrong here now is this turns out to be not such a good idea
because if we do this we will tell the something we will tell him that the decrypted data does not start with zero zero zero two so the attacker learned something about the interval in which the decrypted data is either it starts with zero zero two or it doesn't and this is each other to be enough to if you send enough queries and modify the cypher text you can learn enough information to decrypt data the whole algorithm is a bit more complicated but it it's not that complicated it's it's relatively straightforward it's a bit of math and they didn't put one to put in any formulas but yeah now as I said it was discovered in 1998 so TLS 1.0 introduced some countermeasures and the ID 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 thing this prevents the attacker from learning whether your data is valid or not in 2003 research team figured out that the counter measures how they were described in two years from when over incomplete and also not entirely was Nakia 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 they were able to make to create an attack that still worked despite these countermeasures so more counter measures were proposed and in 2014 there was a paper that Java was still vulnerable to blind both attacks in a special way because they used some kind of decoding they 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 open SSL although that was not practically exploitable in 2016 there was a so-called drone attack and the drone attack was a blanket attack in SSL version 2 now you may wonder as ever who - 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 ts 1.2 and decrypted with the server that still supports SSL version 2 so that was the drone attack and then last year I thought maybe someone should check if they are still service vulnerable to this blind buffer attacks so I wrote a small scan tool and started scanning and scanty Alexa top 1 million the first hit was facebook.com/ was vulnerable and turned out from from the top 100 pages roughly a third were vulnerable and in the end we found like 15 different implementations that are vulnerable probably more but these are the ones we know about yep and just I think a month ago there was another paper that there also you can use cash aside channels which is mostly interesting if you have a cloud infrastructure where multiple servers are running on the same hardware which you can also use to perform these blind bhai texts 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 data that describe the countermeasures to these black bhava attacks so we knew about them since before kill at one point also there was a small chapter what you should do to prevent these attacks and they may figure out ok that's not enough we need to have more counter measures and so what you I mean what you can clearly see here it's it's getting more and more complicated to prevent these attacks so with every new TLS version we had more complexity to prevent this like Maha attacks these were just two examples there are 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 against weak areas freak which can protect issues in the handshake and compatibility with old versions 332 which attacks some block ciphers that have a small block size tripl handshake which is a very complicated interaction of different handshakes the general trencher was that in TLS 1.2 and earlier if there was a security bug if there was a vulnerability and the cryptography you what people did was we need a workaround for the security issue and then if this background doesn't work is not sufficient we need more backgrounds 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 to secure algorithm there so let's secure algorithm take whatever you want which in practice meant very often still the insecure modes for use because like for all of these things they were moves available until as 1.2 that didn't have these vulnerabilities but they were optional but and I think that is the major change that came with TOS 1.3 was a mindset change that people said ok 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 pls 1.3 was that a lot of things were deprecated so we no longer have these CBC modes we no longer have our C 4 which is a another cipher which was problematic we no longer have Triple DES which has these small block sizes we still use GCM what but we no longer use it with an explicit nonce which also turned out to be problematic we completely remove RSA encryption we still use RSA but only for signatures we remove hash functions that turned out to be insecure we remove diffie-hellman with custom parameters which was yeah what turned out to be very problematic and we removed elliptic curves that kind of look not so secure but also there was something that some academics looked at TLS and 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 these analysis have contributed to design TLS 1.3 to make it more robust to attacks so this is anything 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 the security is nice but what we really care about or maybe some people really care about the speech right 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 I've I'm throwing here the handshake and this is
very simplified I kind of only added the things that matter to make this point but if you look at 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 notes it's the perks then the server sends back which encryption modes it wants to use and a key exchange and then the client sense is part of the key exchange and the so-called finished message and then the server sends finished message and then the client can start sending data in TLS 1.3 we have compressed is 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 think data are much faster so yeah we remove one round trip from a fresh handshake
there's 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 where we're reconnecting using a key from a previous section and we also protect more data which may avoid some attacks where an attacker may fill with the handshake these were more less theoretical texts these are also prevented in TLS 1.3 yeah Sotiris 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've put a link here and I will put the slides online so there's also something called
the zero role to a pan shake 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 0rt 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're sending and then send it again and the server may think okay now this request came twice so I'm doing twice what this request was supposed to do so there are some caveats with zero entity 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 there let's look at HTTPS which is the protocol we're using usually if you look into the HTTP standard it says something that a get request has to be even potent and a post request does not have to be it important 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 I get requests are either potent that means they are safe for zero round-trip connections the question is do bad develop sorry [Music] you can do a little experiment if you meet someone who's a web developer ask them if they know what it important means and when they can use it important requests and when they cannot yeah so in an ideal situation where web developers do know that we can use the arathi safely with TLS 1.30 at Atia also does not have a strong forward secrecy as a normal handshake so there's kind of a trade-off here because this pre shirt 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 data so this looks a bit problematic and many speculate that the future texts will see until at one point 3 that at least some of them will focus on the 0 RTT mode because it looks like one of the more fragile parts of the protocol but it gives us more speed so people wanted to have maybe the good news is 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 yeah ok 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 here the new version number four the protocol version here's a by a 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 s l 301 okay that that looks strange then a few lines later you have a version here that's 1.20 303 but we thought this was Cirrus 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 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 a 100 40 s 1.0 if TLS 1.0 came after SSL version 3 which kind of makes it version 3.1 and that's how we encode it like tears 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 vial ??ktem was
the so-called record layer and this is kind of a protocol inside the TLS protocol which has its 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 is kind of 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 then only speak the old version so 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 is an extremely complicated mechanism here so the client connects
and says yeah hello I speak TLS 1.2 services ok I don't know TLS 1.2 but what's the highest version I support its TLS 1.0 so he sent that back and then they can speak here as 1.0 and in case the client still supports that and we have a connection this is very
simple I would think so 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 right I mean it's it's very simple but I was saying earlier we were talking about the real internet so and on the real internet we have Enterprise Products in case you don't know that an
enterprise product something that's very expensive and it's buggy so so yeah we will have webpages that run with firewalls 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 this very new version it's from 2008 I mean that's 10 years in enterprise yes it'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 prowler introduces a new TLS version and everything breaks then users will blame the browser and then you will say yeah I will no longer use this browser I'll now switch back to Internet Explorer or something like that so browsers need to trial this somehow
so what the process 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 were low 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 ss Everton 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 okay Windows Phone 7 used it but on these Nokia phones they also never got an update but okay but like normal browsers and servers at least use TLS 1.0 I mean they maybe didn't use of Kiev 1.2 but they used here s 1.0 but we have these browsers that are trying to reconnect if
there's an error and so what an attacker could do is that the attacker wants to exploit SSL version 3 so he just blocks our connections with a newer TLS version and therefore forces the client to go into SSA Worthen free and then he can exploit this attack that only works on SSL version 3 so so browser sir okay these downgrades according security issues what do we do now we could add another workaround so there was a standard called s CSV 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 nothing 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 am 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 browser stopped doing these downgrades so attacks like poodle no longer worked
oh how I should just said they fixed it no of course they have not fixed it I mean they fixed it for tearless 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 Souls and would have to introduce downgrades again and all the nice security would 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 feels 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 other 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 he'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 Griese 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 service 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 TL as well but we can just randomly add them to this extension in order to make sure that if a server implements is incorrectly they will hopefully recognize that early because there will be connection failures with normal process yeah yeah so 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 greased mechanism to make it future-proof so now we can ship TLS 1.3 right then there was this middle box issue so so in oh sorry that's that's the wrong year it must be 2016 sorry in in 2016 in summer TLS 1.3 was almost finished but then it took almost another year till it guard sorry I mix up the yes now that's no it's it's correct sorry in 2017 the 80s 1.3 was almost finished but it took till 2018 till was 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 this connection failures turned out where devices that we're 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 were used to it so let's just drop it yeah so yeah this is a strange keyless package I don't know what to do with this I'll drop it these were largely passive middle 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 enter I don't know and they were dropping traffic that looked like years 1.3 and then the browser vendors proposed some changes to a 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 sourced just supposed to be ignored so one such message is the so called changed cipher spec message until s 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 sent 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 were a few other things and then eventually the failure rates got low enough that 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 HTTP server they have network support and we have to talk about these people here so if you
remember the the Snowden relations one of the things that got highlighted there was that there's a random number generator called dual EC drbg and that has a backdoor and basically these days everyone believes this is a vector by the NSA and they have some secret key so they can 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 offer ten million dollars to RSA security so they implement this random number generator and then there's the there was a proposal a draft for a TLS extension called extended random that add 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 every kind of one 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 rad well EC random number generator and figured out that if you use this extended random random extension then it's much easier to exploit this factor in this random number generator and coincidentally RS ace TLS library be 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 okay this was no big deal right but actually it seems these these Canon printers they had enabled this extension and they used this are say be safe library and enable 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 there so that the server knows what kind of extension this is and for this implementation they just use the next available number and it turned out that this number collided with one of the mandatory extensions that TLS 1.3 introduced so so these 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 they the been the 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 continued
to show up for example recently Java which is like also very popular in enterprise environments it now ships
with the 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 Greece mechanism and it helps a bit like it prevents these version intolerance 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 will use for three months and then we will deprecated 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 Voris be and here's a blog post from Cisco where they they want to use machine learning to detect bad TLS traffic because they see the all this
traffic is encrypted and we can no longer analyze it we don't know if members in there so let's use some machine learning it will detect that traffic so what I what I'm very worried that will happen here is that the next generation of of TLS deployment issues will be a I supported TLS intolerance issues and it may be much harder to fix and analyze I'm 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 are these black Baha'i texts that I talked about earlier and then they 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 TS 1 by 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 something 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 Peterson is 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 phone and not quite empty beer cans my exactly where are 15 and ours a key transport disappeared from the spec on about a dozen crafts ago I know the banking industry is usually a bit slow off the mark but this takes the biscuit okay there were several proposals then
to add a visibility mode two tiers 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 Tillis working group what 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 if the industry eventually went to Etsy which is the European technology standardization organisation and they recently published something called Enterprise TLS which modify still has won three in a way that it would allow these decryptions the IETF protested against that and primarily because of the they used 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 tearless ok but yeah yeah yeah that's one point three is finished you can start using it you should update your service 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 yeah that's it and I think we have a few minutes for questions [Music]
all right young as Hana management 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 this we possibly can now maybe you just go ahead over there and mic - the question
is if there's a way to prevent the use of that enterprise - yes 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 might reject it although the problem is some service may also use it for an optimization so there are longer discussions on this question so yeah I cannot fully answer it but they're more or less there are options all right 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-piece [Music]
meant something like sequence numbers 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 all right then let's take a question from our viewers in the internet the
signal angel please [Music]
like 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 yeah all right then let's
take a question from Mike for please yeah it's also related to the enterprise TLS the browser can connect to
enterprise TLS without any problem yeah so it's built that it's compatible with the existing TLS protocol Thanks 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 all right then let's take another
question from the interwebs
I mean that that's what I said the 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 okay we still have plenty of time so let's go to Mike to please yeah
as you said we have still a lot of dirty
work arounds 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 have passed that you are allowed to use the TLS 1.3 logo or one point although you can do that in theory the problem is you you you don't really want to have a certification regime that people like have to ask for a logo for to be able to be allowed to implement yes and that's kind of one of the downsides of the open architecture of the Internet right we allow everyone to put devices on the Internet so we kind of have to live with that and we there's no TLS police so we kind of have no way of preventing people to use broken TLS implementations even and and I mean people won't care if they have a logo for it or not right all right let's
go to a mic five all the way in the back there okay I have a question about source algorithm and tiers 1.3 because
since quantum computing is getting very popular lately and there are a lot of improvement in industries so what's the current situation regarding here as 1.3 and all those quantum based algorithm break the complex view into polynomial times yeah there's no major change here so with TS 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 to introduce a quantum safe handshake but they only ran it for a few months and 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 are can be attacked with quantum computers ok so I think we are getting to our last or
second to last question so let's go to Mike 3 I think you've been waiting the longest okay in all the versions of TLS there was a
problem for small devices such as I see and the industrial devices has there been a change in one point free to allow them to participate I mean I'm not sure about the entire you mean with the problem I mean our Parliament's 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 the I mean the 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 ok 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 [Applause]
[Music]
Feedback