Securing The Future of TLS 1.3

all right good afternoon everybody TLS 1.3 it's been about 10 years since the last version of TLS came out in 2008 with TLS version 1.2 so in 1.2 a lot of things have changed because it's been 10 years lots of significant cryptographic advances have been made lots of breaks against implementations of TLS even the protocol itself had a couple problems found in it over the past 10 years so a TLS 1.3 a lot of people have worked very hard over a really long time to make sure that it's cryptographically as best as it can be early last year mozilla released some stats talking about the number of HTTP connections on the internet and finally after a long time of having the web up

we finally reached half of the TLS connection half of the connections over the web where TLS and it's been increasing ever since so now I think we're up to probably 65% or more and that's thanks in part to people like CloudFlare providing free HTTPS on content on their content delivery network certificate authorities like let's encrypt providing free certificates for people to use and people like Google and Mozilla who have been increasingly making their browser warnings for regular HTTP content progressively scarier and so web sites that maybe had just secured their login page instead of their landing page now whenever somebody goes there and tries to type in a password or search for something on the web site now the

browser bar will change to be read instead of just staying a neutral color like it used to the TLS is a product that's our protocol that's created by the internet Engineering Task Force the IETF so the ietf is an international organization people from all over the world come out and meet about three times a year and they talked to each other on mailing lists continuously and they're responsible for things like TCP email the things that people use all day long and that includes TLS they've been working on TLS 1.3 since probably around 2014 or even 2013 and it got a couple false starts and do-overs but it's finally almost ready to be released so the number was just a sign recently

Thursday a couple days ago and it's in the final stage right before it becomes a fully fledged web standard but before we get too much into What's in TLS one three we should talk a little bit about the past so we can understand why it's better so in all the prior versions of TLS you notice SSL is a prior version of TLS they changed the name because Microsoft didn't like calling it SSL because Mozilla came up with that there was a big battle and so they said fine fine we'll just call it something different and Microsoft was happy with that that's a TLS 1.2 that's when the IETF took over standardization so SSL one two

and three those were all done by Mozilla or Netscape at the time and one was so bad it didn't make it out of the laboratory two was a little bit better but it was still pretty terrible and they came up with three and after three everything seemed to pretty much settled and they were just little tweaks here and there the handshake is the most important part of TLS it's the handshake is what sets up all of the security for the whole rest of the connection so in there you agree if you're using certs what search you're going to use is it just the server using a certificate or is it the client as well what type of

authentication algorithms are they going to use how is the to prove who it is to the client though you have to use some type of cryptographic algorithm which one is it what cipher are you gonna use to do the encryption there's a whole plethora of those and then finally how do you get the key that you're going to use in the encryption with TLS all the actual data that gets sent over it's encrypted with symmetric cryptography so that means both sides have to have the exact same key otherwise one person's going to send data and the other side's not going to have any idea what to do with it so the key transport or key agreement

between those two sides that's really important because you don't want to just yell out your key in front of the whole world and then what are you encrypting it for everybody's going to be able to see all of the data so this right now is a poster that I made showing the current best practices in TLS so that means it's using elliptic curve key exchange so there's different ways to get that key cut across and so you can see on the bottom of the client-side the key exchange piece is coming across so both clients and servers can use certificates so the first thing you need to agree on is the certificate and the authentication algorithm that you're

going to use with that certificate to prove your identity certificates are just a key that's tied to an identity so they're they're sent across and structures called certificates but all of that is just a binary blob tying a domain name or a person's email address or some other type of identity to a cryptographic key and so there's lots of different types of cryptographic keys that you can use with TLS you can use an RSA key that seems to be the most common although the ECDSA is slowly sneaking up as part of things that as part of the the ones that people are using more and more there's also a different way to do the server authentication and client

authentication both so at the same time if both sides have the same key already they can just use a pre-shared key it's PSK there so that's used most of the time like if you're setting up a VPN between two switches on the internet and you're an administrator and you can go log onto one type in a long password there you can go log on to the other one type in the password there both sides have this key that's been pre shared and they can talk securely and using the algorithm of the PSK they can know that nobody else has intercepted the communication and then there's this other one none yeah you can use TLS without using certificates but that

means that anybody can step in there in the connection and pretend that they're the other side so this was an option that somebody wanted to have in TLS and some of the earlier versions they wanted to be able to encrypt the data but didn't really care if somebody else was going to step in and try to do an active attack so if you don't have a cert that's cool you don't need to bother with getting all those certificates provisioned out and making sure that they rotate every two years three years three months but you also don't have any protection against an active attacker but you do have a protection against a passive attacker so people that just

needed protection against those passive attacks the none was good enough for them the problem is a lot of the times with none people that were providing server software or some clients we're just configuring gimme all of the ciphers and all of the protocols and all the types of keys and just let my survive let my server do everything it possibly can and when that happens nones included in there and if there's an active attacker he can cause the connection to fall back all the way to not using certs at all which we would consider bad if you're trying to protect all that data right next thing you have to agree on is the cipher so there's plenty of ciphers here

even none the majority of connections right now are using some type of AES so I have two types they're some of the newer ones are using this algorithm called ChaCha 20 which is super fun to say and then there's the old standby government algorithm 3des that IBM came up with back in the 80s that had a significant protocol break against it back in 2013 or so but it's still used out there because some of the clients and some of the servers can't go better it's like Windows XP is still stuck in three days luckily everybody's already off of windows XP like the government computers and the heb returns desk I'm sure so AAAS is a block cipher so

there's two major types of symmetric key ciphers so block ciphers are ones that take big chunks of data and encrypt it throw it into the encryption algorithm cha-cha 20 is a stream cipher with a stream cipher you have a cipher that generates a whole bunch of random numbers and then you take those numbers just as many as you need no more than you need to and you just XOR it with the plaintext and as long as that stream generation is secure then you can have a secure connection rc4 is another one I didn't include on this slide it was also broken around the same time as Triple DES it's another stream cipher but it had some problems getting enough

randomness in the beginning and so an attacker could cause it to start over and start over and start over and whenever you did that you could guess the cipher text and be able to decrypt it that way but just towards the beginning of the connection which is why he had to keep starting over and over so you can see there's the two modes of AES up there the CBC stands for cipher block chaining and that's a particular mode that has been shown to have some issues recently so in that intervening ten years that's when some people came up with about three different attacks on the chaining block cipher mode where if you could control some of the data that

was sent from the client to the server like through JavaScript or a flash program that you're running in their browser or Java program you're running in the browser turn-off Java you could control the data that was being sent and then that could let the attacker guess plaintext pieces of what you were sending over the connection so you could decrypt things like cookies or authentication tokens or if it was email everybody and their email whenever it's sending to the server your username and password is encoded right there in the front part of that message so if you wanted to attack an email server that was using that mode you could just get it to keep sending

that email because email servers like to retry sending emails if there's a problem and whenever that happens then you could get the users name and password off of that the best one to use of course is GCM or the cha-cha 20 there's two different places that you'd want to use each of those the a s GCM is really great on desktop computers so intel has a cryptographic coprocessor that they include in their chips and it knows how to do a es really really quickly so whenever you do that it's really fast to do AES on a desktop but for arm press ARM processors like in your phone they don't have that cryptographic coprocessor that knows how

to do a a es really well so for mobile devices you might want to consider using cha-cha xx both of these ciphers are what's called a EAD that's authenticated encryption with Associated data it just means that the cipher text that gets sent also has a little tag on it that authenticates that it's the actual cipher text sent the chaining block cipher mode doesn't so if an attacker wanted to they could mess with some of the cipher text change it as it's going to its destination and then the destination server while it tries to decrypt it if it's decrypting it then it will choke on bad encryption and say whoa this doesn't look right and send

back an error when that happens it gives off a timing attack so that's why the chaining block ciphers aren't really good to use anymore because of that protect that added protection that you get from the a EAD type ciphers unfortunately both of those are only in TLS 1.2 so if you're stuck on an old server system you can't use these better ciphers so this is a guy from Google that runs part of their TLS stack Adam Langley so what he's saying is that everything below TLS 1.2 is cryptographically broken it might not be broken easily by an attacker that's got the latest tools but cryptographically from a theoretical standpoint it's already broken so you don't want to use it because as Bruce

Schneier says attacks don't get worse they only get better so you want to get off of the older stuff as fast as you can now for the key exchange there's two types a static where you use the same key every time an ephemeral where the key keeps changing every connection so with the static exchange you're always using the server's certificate key to do the key exchange with an ephemeral key exchange you're changing that key exchange key every time so if you're doing ephemeral the keys that you're encrypting with have absolutely no relation to the key that's in the certificate but with the other one the static he exchanged the certificates key is used for doing the key exchange and

what that means is a client is going to take a secret seed and encrypt it with the server's public key so now only the people that have the server's private key which should just be the server can decrypt that connection and that's another way to authenticate who you're talking to because if the server can decrypt your message with that secret seed for the key then it must be the right one so whenever you're using ephemeral key exchange that's using something called forward secrecy and sometimes can call perfect forward secrecy but most people don't call it that because nothing's perfect anymore so what that does is use things like elliptic curves or another key exchange mode called diffie-hellman

and what that does is to let both sides come up with a brand new key for every connect swap public keys and then use their own private key and the other person's public key to agree on a secret now through the powers of math and elliptic curves they come to the same answer and anybody looking in the middle they can see public keys flying back and forth but because of the way that math works out they can't derive that secret and well they can but it's gonna take till the Sun burns out or maybe even longer because they're gonna have to do it manually the reason why you don't want to use a static key exchange anymore is

because anybody that can grab your servers private key can now read back the entire session that you had so back when the heartbleed vulnerability came out people that only had static key exchanges on their servers were really worried about that because it meant if somebody had a big facility in the middle of Utah that had lots of servers with lots of storage and data in it and they were maybe listening to all the connections going over the public Internet if they ever broke your key or if you ever lost your key or accidentally put it on pastebin they could go pull all the data that they had stored up and go decrypt it so if you or

maybe somebody that was sending email to an email exchange that only had the static heat on it and the FBI subpoenaed that email exchange for the private key and had they been keeping all that data going to the email exchange they would have been able to see all the plaintext that you had every mailed back or forth from that and so it's definitely not best practice anymore and people are trying to get away from it as fast as they can

so now we made it to TLS 1.3 so this is what it will look like as soon as it's released so it's this is kind of like a sneak preview on it so it's probably gonna be official in the next week or two but right now it's it's held up for the final review from the author of it it's Erik Rescorla he works for Mozilla now so he's doing his final pass over of all the changes that were made by the editors and then once he's done then it gets released and it'll be an official standard we already know the number you can see that they plan something in advance because all those those numbers

line up it's pretty cool how they did that so the the last RFC that got published is something like 8401 so they they skipped over a whole bunch of numbers and went up to the next one that matched the pattern instead of just going with the next one all right so the TLS 1.3 handshake like I said for the other ones 1.2 and below the handshake pretty much stayed the same for all of those connections there's not really any difference 1.3 though significantly changes the handshake and how it's done you still have to agree on all the same things you still need a cert you still need a authentication algorithm cipher the key but the way that it happens and this

time is different so RSA is still supported for certificates but not for key exchange we'll get to that in a minute though the there's a new signing algorithm this time with the TLS 1.3 server proof so the one that's used in all the prior versions of TLS is pkcs number one version 1.5 there's been cryptographic problems found whenever you use that especially if you use it with certain settings so rather than continue to use something that's even just theoretically or barely broken they said we're just gonna move to the more secure one and everybody's got to redo their code anyway so we might as well do that so they're using PSS for the key exchange for the proof you can do ECDSA

certs as well same same as patellas 1.2 and before the proof message the thing that gets signed by the certificate to prove that the cert that the server is who they are instead of just signing a little piece of the key that's pretty much the same or could be the same for every conversation instead what they sign in TLS 1.3 is a hash of everything that's been transmitted in the conversation before that so there's no chance of replaying these server signatures so theoretically an attacker could have grabbed a signature from 1.2 that the server had put is its proof and used it again in a TLS 1.2 style handshake but with TLS 1.3 because it

does the whole transcript it's got everything the client sent up to this point everything the server's sent up to this point and then it hashes all of that information and signs that hash and sends it along the ciphers have cut down significantly so they they looked at the no cipher none null no encryption here and they said we think we should get rid of this and if somebody actually stood up and said no but I use it can't can we keep it please and there was some back and forth back and forth and they decided no just go ahead and encrypt it's not going to be that much harder for your servers the only person that I

know that's really doing that and and means to is the Microsoft Windows Update so they have it hard-coded in all of the other libraries that Microsoft has never to use the null cipher for encryption encryption but for a Windows Update they have it in there I guess if you're trying to serve like billions of computers all over the world it probably does save a little bit of processor speed if you don't encrypt every single byte especially when they're freakishly huge updates that are going out over the wire but they're gonna have to change the ways for 1.3 AAS is a mandatory cipher so if you're implementing TLS 1.3 and you're purporting to implement the full

standard the standard says you have to have aes GCM oh and you should have ChaCha 20 but it's not a mandatory cipher yet both of those remember are the authenticated ciphers so you'll notice that the AES CBC mode is not here because of the problems that they have with CBC mode they kicked it out so now there's only only the best

for the key exchange we only have a femoral key exchange so we talked about why RSA was so bad or the static exchanges that you had so this is probably the most contentious change that they made to TLS 1.3 and part of the reason is it turns out they found the IAT I found out probably about two years after they decided to take out the static key exchange a little bit late to the party an association of banks across the u.s. came and said we were using that where'd it go and the IETF explained to them like it's not safe it's not secure we don't want to have that in our TLS libraries we don't want people accidentally

configuring it and then shooting themselves in the foot and having somebody be able to decrypt all of the communication they've sent and so they came back again and said pretty please they shot him down again with some stronger language but they kept going back and forth trying to figure out some way so there's cryptographic ways to make it look like you're doing in the ephemeral key exchange but not actually do it and they wanted the IETF to standardize a way to do that and there was very strong pushback and very strong feelings from a lot of people in the ITF but that went against the spirit of what the AIA IETF was trying to do so recently the

IETF came out with an RFC talking about pervasive surveillance and assisting governments people like Iran and Turkey that would intercept civilian communication decrypt it and take a military action or police action against the individuals and because of things like that the ITF took a very strong stance saying we don't want this type of thing to be standardized we don't want to assist in helping those governments do this and so that's why they decided on using only ephemeral key exchanges the problem is a lot of those banks and other large enterprises here in the US are using that to do things like web application firewalls or assist in debugging connections so it's super useful if you have something going wrong

on your web server that's only going over TLS to be able to look at the plaintext messages and see what's going wrong and you used to be able to just go over to the server and grab the private key and put it on your local desktop and look at all the data going over the connection but you know that also means that you could take that private key and go look at everybody else's connections and everybody else's data semi teashops felt that was fine or they only let certain trusted individuals or certain trusted computers do it but with TLS 1.3 that options now off the table and software vendors have to go in and find

different solutions to be able to accommodate things like debugging and chrome and firefox have taken an approach that makes it useful for an individual developer to be able to go in and set a debugging flag where the browser will actually write out all of the session keys so all the things that you need to know to be able to decrypt the individual sessions without knowing the server's private key so if you are going to a web server you can go into Wireshark and configure Wireshark to look at this list of keys and pick out the best ones that it can use to decrypt all the sessions and so locally you're able to still do this type of thing and

see all the decrypted connections so you can assist in debugging or things like that one of the other things you can see here is in the TLS 1.2 handshake there's more arrows over here there's less arrows so generally means it's a lot faster and we can talk a little bit more about that and second the other thing to notice is the red means encrypted so TLS 1.3 gets to the encrypted pieces a lot faster than TLS 1.2 so the only thing in 1.2 that's encrypted is the very last message and the finished message basically all it is is it's a block of zeros that's encrypted with the key so that way you know after you're done

trying to agree on all the ciphers and protocols and certs once you get that last message you go okay can I decrypt this and if the answer is all zeros then you're good otherwise you probably should start over and try again or there's somebody messing with the connection with TLS 1.3 however you start encrypting as soon as you can so with the certificate and the certificate verification that proof that the server is what it is and then on the client hello once you get the information that you need to be able to know what key to generate you can immediately start encrypting so encrypt the finished message and then you can also tag on some HTTP data or whatever protocol you

happen to be doing TLS over so you get that first foray into the application layer a lot quicker with TLS 1.3 there's also another mode a special mode for TLS 1.3 called zero RTT which stands for zero round-trip time that means that the client before it goes back and forth even once with the server can automatically or can send on that initial handshake message some early application data so it's it's good for things like if you're doing a get slash to a server to get the webpage downloaded you throw that out very first and then the server whenever it gets your message it automatically knows to send you back the webpage so on that very next message it has the response

and it can send you back the the first bits of the webpage in there so the way it gets to that encryption key remember you still have to have the same key on both sides the encryption key that it gets is based off of a pre shared key that's negotiated in a previous handshake so if you go to Google and you establish the TLS 1.3 handshake the first time the server will send back a message that says hey if you ever want to talk to me again use this pre shared key and then on the Google side they'll take that pre shared key and distribute it across their servers so next time if you happen to go to a different server

they won't know about you yet but Google has secret back channel this pre shared key to all of their servers so I'll have that so whenever you encrypt that initial message in the zero RTT mode the server will be able to look at its share of the pre-shared keys and be able to resume and respond to your the problem is this early HTTP data that's not protected with forward secrecy so because it's using a pre shared key that pre shared key is distributed among a bunch of servers what happens if an attacker copies that message and instead of just letting it go to the one server that you were trying to go to what if it

takes it and sends it to every Google server on the planet all at the same time that might not be a big deal if you're doing something like give me the homepage for your website but what if it was a message more like buy me 10,000 bitcoins that's a lot of money and the servers are all going to process that request and then your bank accounts going to be really really really negative so in order to protect against that there's some very very stark warnings in the TLS 1.3 RFC that say this is up to the application level the app has to know about zero RTT and has to be able to make a good decision on

whether or not a request or data that gets sent over that channel is something that it's safe to be repeated a billion times across every server and if it's not then you need to not send it that way if it's just give me the home page then yeah that's fine and you're going to get your answer a lot quicker that way so let's race the different protocols so here in the bottom we have the the legend you have the cert and authentication algorithm the cipher the encryption key and then I tossed in the HTTP request and an HTTP response so first up we got TLS 1.2 the client sends over its first message it's got what

ciphers a list of ciphers the client supports a list of the types of certificates the client supports there's no keys or anything that it can decide on because it doesn't know what the server has so the server sees the clients list and says oh yeah yeah that cipher looks good we'll use that that cert algorithm looks good we'll use that one and here's my certificate once the client gets that it can either you either using the ephemeral key exchange or the static key exchange it can send the server the encryption key or the message to allow the server to generate the encryption key so after that we've got everything down we know what to do

but the server still has to send back a message it says ok we're good now start talking then finally you can do your HTTP request and response so that takes a pretty good long while because it took so long they decided after looking at a lot of Internet traffic the some of the messages could be cheated or they call it false start so there's there's a way to send some extra messages so let's look at how that looks so the first two back and forth the first round trip is the same then whenever the server or when the client has the encryption key that he knows about it can also tack on to that an HTTP request before it's

heard back from the server ok yeah let's start talking encrypted lis so they looked at the data and recognized that most of the time the server all would respond with ok yeah we're good let's start talking so there wasn't really a need to wait for the server to tell you you're good you could just assume that the server is good because that's the way it worked most of the time and so that ended up saving a whole round trip off the connection so they started implementing this back in I think around 2012 or so and a lot of the clients Chrome and Firefox things like that they started using it so now with TLS 1.3 it

starts off looking a whole lot like TLS 1.2 the client sends its information the server says ok yeah here's a cert here's the cipher we're going to use but in the very first message the client sends because all of the connections are now ephemeral key exchanges the client can send its ephemeral key without having to wait for the server to say hey let's use the ephemeral key exchange because it already knows it's going to say that because it's TLS 1.3 so it'll also send the encryption key along with that and then the following looks just like TLS 1.2 you so you improved a little bit you got the encryption key faster but it's still the same number of round-trip

but with the fault with the zero RT t mode you can get it a whole lot faster because this is doing a resumption the client already knows everything that it needs to to start the conversation and it can send that initial HTTP request and the very first message that it sends which means the server can respond with the HTTP response on that very first thing that it sends back to the client and as part of the zero RT t mode what it does is it renegotiates a new encryption key to use for the rest of the connection so the server as part of that response will say hey here's my my new ephemeral key go ahead and

recalculate a new encryption cipher a new key to use for the rest of the encryption of this column of this conversation so measuring this in going across the Pacific because it's a round number the Atlantic I know it's more popular but the numbers don't add up as well so 200 milliseconds to go across 400 for the TLS 1.3 normal mode and the false start mode to get that connection to get that response back or 600 milliseconds for the old way of doing TLS with without the false start in there so you can see from this that a lot of the seconds add up quite significantly whenever you start throwing a whole bunch of different connections across the

especially if you're going across the ocean but even if you're going to serve it closer to you you still save a whole lot of time multiply to go off across a whole bunch of clients that saves everybody a lot of time all over so with the with the TLS 1.3 what they started doing as they got closer to finishing the RFC two years ago where they were almost done they started rolling out drafts on test platforms like Google and CloudFlare properties would roll out an initial version of TLS 1.3 and they would turn it on for either if you ask them to nicely or for a small section of their users and whenever they did that

they started finding little problems with things like firewalls so a lot of times firewalls or hard code things like a TLS connection always starts with these hex digits and if it doesn't then it'll block the connection and it's not good if you want somebody to adopt your protocol that happened with TLS 1.2 and it was standardized in 2008 Microsoft didn't turn it on by default until around 2014 because it took that long for people to upgrade all their old firewalls and application knowledgeable middleboxes so in order to prevent that type of problem with TLS 1.3 they started trying out drafts to see hey we think this will work let's try it out in the real world and

see what breaks and lots of stuff broke Google ended up kicking University off the internet because they all use Chromebooks and they were going through a certain vendors middle box that didn't know anything about TLS 1.3 and couldn't handle it and so whenever I saw it it said I don't know what this is kill it and somebody at Google made the worst mistake of having the server that sends out the updates to say oops that was a mistake roll back they have graded that too TLS 1.3 as well and so they couldn't roll it back and so the university was pretty mad at a couple of people at Google for sending that out without an option for

them to turn back off except for one at a time going into the the deep internal settings of Chrome so you learn from that mistake fixed a couple things tried it again they still had problems now with that vendor not with a couple of the other ones but they still found a couple edge cases where things were expecting something that looks like TLS 1.2 whenever it didn't see that it barked all over the connection and no traffic flowed so they ended up saying okay fine we're gonna completely change the way we negotiate the protocol so now instead of saying in the first little section of bits in TLS 1.3 and 1.2 where it says I

do TLS 1.2 it there we're gonna put in an extension where none of these middle boxes are looking so it shouldn't break anything right we're gonna put it down there and we're just going to hard code TLS 1.2 up in the initial thing so now all the TLS 1.3 connections whenever they come across the wire they say I'm TLS 1.2 let me through and all the middle boxes say okay cool come on in it's a party so negotiation is also different in TLS 1.3 but it's only so that it can get rolled out faster so what they were able to do is roll it out and last month at the beginning of the month it was

already at 5% adoption over the clouds layer servers and right now they finalized all the the binary bits of TLS 1.3 like I showed you they've got the draft ready to go as soon as that rolls out open SSL is going to release their next version it's going to have TLS 1.3 in it Microsoft is working on their version of it Apple's already got their version ready to go Firefox has had theirs and beta testing for a long time so the Internet's already ready and even chomping at the bit ready to go TLS 1.3 both for security bill for speed now available mostly these are some of the things that I'm getting ready to work on so I'll put these out on my

website pretty soon this is a kind of a deep dive in the weeds if you will for TLS 1.2 I've already got them done and mostly written up I just haven't released them yet I'm gonna do the same thing with 1.3 so you can look at the actual bytes going over the wire and see what they're used for and how they're used so you can look at my website ceme and that should be coming up pretty soon thank you for coming out appreciate it [Applause]