 So please welcome Nick Okay, hello, is this thing on it is okay. Hello everybody. I'm Nick I work yes at Cloudflare everybody's favorite CDN and I work on applied cryptography and I'm gonna talk today About the most interesting protocol in the world transport layer security so If anybody has used this browser do you recognize this little icon right here? This is This is Netscape 1.1. This is the first Web browser that had SSL that had some sort of layer security built into it And it had this little icon here that looked like a gun and maybe a pin from a grenade But if they're connected then that means your site secure they eventually improved it to this little lock icon that evolved to this Nice green lock and the address bar that we all know and love But HTTPS SSL this this whole encryption thing on the web enabled a revolution starting with E-commerce you could go to this beautiful website here with your with your browser and then buy some books or Buy somebody's used stuff It actually was a revolution and To to put into context This is this drawing that we did once of what the internet looks like and There's all these different links that connect over all these different protocols But to access websites it's really point-to-point and you go from either your phone to a data center or your laptop computer to a data center and it it's you know way to get information and websites and This originally HTTP is a plain text protocol. Everything is sent without any encryption or encoding. It's just letters on the wire and After this came out people wanted to add some security so This protocol was invented called HTTPS and the s is supposed to stand for secure, but Lately it's been sort of another s word So HTTP HTTPS This is HTTP plus security and right now what that means almost exclusively is this protocol called transport layer security that you've all Heard about and it provides data encryption and integrity as well as Authentication of the server tells you what website you're actually going to and gives you a way to verify that that's who it really is So this is This is a this is a messy details talk So as with anything the devil is in the details. So let's go a little bit back to the beginning SSL was Secure sockets layer was the original protocol that Netscape invented back in the early 90s to encrypt the web and It was invented by this guy Kip E.B. Hickman and I you know, I heard some stories about this I saw that Moxie Marlin spike In Def Con 18 sort of tracked him down and had a phone call with him But there was this story about SSL V1 being presented and I emailed Philip Hallen Baker and he's kind of described the setting in which SSL one was presented and it was by Mark Andreessen at MIT to a group of around six people and The people in the audience apparently broke it right away because there was no authenticity checks at all So SSL V1 was an auspicious start to a security protocol It's come, you know completely unauthenticated so To get back to it it was evolved and I'll get into how SSL became TLS and you know became something that we use every day but it really breaks down into two different pieces one is public key cryptography and this is how you as a browser and your server sort of established shared keys and The identity of the server and data encapsulation, which is you want to send data to the server and back You have to encrypt it somehow and authenticate it This key establishment part happens with this with what's called SSL handshake and this is you know pretty complicated There's pieces going back and forth But let's focus first on that little check mark on the left which is certificate validation And this is how TLS provides authenticity This beautiful thing that we've all built together called the public key infrastructure and so just Bear with me for a second like how does this work? This is it's based on something called x509 certificates and certificates are Files with different things like the identity of who you are a public key and they're usually digitally signed by a certificate authority and This certificate authority has a certificate itself and then Oftentimes that signed by another certificate authority. This forms a chain of trust and as long as you can trust The sort of dark brown certificate there then you can and these signatures are correct Then you can say okay. Yes, this is someone I trust to issue certificates for websites and Therefore this site is really who it is So this this whole chain of trust thing seems really easy, right? It's just Checking digital signatures checking making sure that the the metadata inside it is correct and matches the site you're going to well Yeah, boy was that boy were we wrong about that being easy So I'm gonna explore a couple different ways in which this was completely messed up including implementation bugs intentional flaws and issues of trust so To make it more clear. This is what we mean when we've validated certificate This is in that check mark in that first diagram is as a client You parse the certificate you find a parent certificate and you make sure that the signature on this Leaf certificate is signed by the parents public key and if that parent is trusted by you then you're good And you know this this is good and you go on if not you Do the same thing along the parent certificate you check it certificate check its signature and So this is just making sure the certificate is correct. What about actually tying this to your encryption channel? there's really two ways of doing this in TLS first is the RSA method and In this method as a client you encrypt a Premaster secret a bit of data that you want to share with the server with the server's public key and send it Over if the server can derive the same keys from that information as you then That's sort of implicit validation that they have the corresponding private key Diffie helman. This is much more recommended by the way What happens is Yeah, you you sign a couple things right at the server signs several parameters that are used to derive these shared keys And you just verify it with the certificate now So there's two things right validate certificate. It's tight certificate to channel If phase one breaks then all you have to do is use some untrusted certificate and the client will say okay This is good. I believe that this is a real trusted certificate go on from there The second phase if there's a problem in that then you can use a real certificate, but a fake signature Has anybody seen this code before? You got one couple hands out here This this is code in a library called new TLS and What this is really doing is it's supposed to check if this is a CA and it turns out if you remember your C correctly That anything other than a zero return value is true and a zero is false What happens here is if that? one call check if CA so the get signed data fails then you return result and That result is going to be a negative number and therefore it's going to say yes This is a CA so this this bug really says if you give it an invalid issuer then. Oh, yeah, this is a CA It's not bad. It's actually completely good as a CA and this code was introduced in 2005 It was discovered in again as a bug in 2014 so in in all Tools that used Linux can you tell us for nine years? This channel binding very this is certificate authority code was was in there This might be more familiar. Has anybody seen this code before this is the title of the talk, right? This is in Apple's common crypto library and again. This is just a simple programming bug Accidentally, there's to go to fails. I I don't really know exactly how you could put to go to fails But from what I understand, they're not using get at Apple for this library So if anybody remembers how you merge Merge problems and subversion sometimes you end up getting duplicate lines Maybe that's how it happened. Some people have considered that it may be more subversive But I highly doubt it but in any case what this does is it'll always go to fail and Go to fail will mean this key exchange. Yes is correctly tied So all you have to do in this case is just use a Certificate that's valid and put in some garbage as a signature and you're gonna be good So these are these are easy, right? These are just simple programming bugs and they completely invalidate the authentication in in TLS Let's look at something a little bit more complicated so there's Several different ways in which you can do dig digital signatures This is the most common for RSA. It's a standard called pkcs number one one point five. It's it's pretty horrible It looks for zero one a bunch of f's and a zero and then it has this digest info Which tells you what type of hash it is and this is an ASN one object And if anybody's worked with ASN one, it's it's not super fun and then the message digest Back in 2006 at the crypto conference Daniel bleichenbacher. I hope I pronounced that correctly. I am in Germany Anyway, see he found that sort of surmise that if you parse this incorrectly and were able to put some extra garbage at the end You can construct a fake signature or some signature that will actually work and this only works if you're using RSA with the public exponent of three and I don't need to go too much into the details of RSA but if you if you do a signature verification you want it to be fast in RSA and That's really an exponentiation with the public exponent So people use three because that's incredibly fast all you have to do is take your message and cube it and then you'll see if that that's actually going to decrypt the message and It turns out that if you can arbitrarily choose garbage in there, you can construct some value that cubes into something that looks like this and Then you can actually make a valid signature on on some certificate and and it'll just work and it turns out that there are several Roots in the certificate authority Trusted root stores in all sorts of browsers that have been around forever that use this public exponent of three So this is this actually was practical if you can put some garbage at the end of the digest But every implementation now checks that there's no garbage at the end but There was recently Another mistake, right? So this is another library Called nss which is very very widely used. It was developed by Mozilla to do all the crypto in Firefox as well as it was used in Chrome back in the day, but Turns out there is another coding error and in this case it's in this digest info and as I mentioned it's asn1 which is It's an encoding format that is is kind of crazy complicated much more complicated than it has to be and there are two encoding formats BER which is what this is named after is the basic encoding rules There are multiple ways of encoding data and you can just put extra zeros. There's multiple The the length of length values is Arbitrary so you can have different length length values And that that actually turned out to be the problem here is that there is an integer overflow in the asn1 length so you could actually put a bunch of garbage in your length and have a several multi-bite length value that it would just skip over the garbage and as with the previous attack you can construct a Message that cubes into something like this by Repeatedly just trying cube roots and there's an algorithm to do that my colleague Filippo on Put it put this up on github so you if you want to exploit this you can do so and your your signatures are gonna look weird Right, this is not what a digital signature usually looks like it usually has quite a bit of entropy But this is a small number and if you cube that you get something that actually looks like like this And it'll this was actually trusted by by Firefox for a while So there are subtle ways that you know programming bugs can can creep in and break the trust that you get from TLS but Speaking of of this issues of trust speaking of the public key infrastructure. You don't necessarily have to Find bugs and flaws to take advantage of it So here's a quiz for everybody In your say browsers at home or operating systems Whatever you use if you're not sort of paranoid like me and have removed CAs how many countries have controls of CAs that Things are trusted that can actually sign any certificate. That'll be trusted. Does anybody have a guess? Too many. Yeah, that's yeah, that's right. It's actually 46 So this is from the EFS SSL observatory data 46 countries around the world could you know just arbitrarily create certificates for any website and That's that's also kind of crazy how do you really trust that this was issued correctly if there are Different entities that are supposed to follow rules, but technically can create certificates for anything This came up earlier in this year and the year before but it's been a Sort of endemic problem with SSL people want to look inside of encrypted data to look for bad stuff Or to say inject ads and Superfish is one of these things it was installed on Lenovo laptops And what it did was it installed its own trusted route into your root store. It made it so that every browser you have Will trust this Lenovo route So there's all sorts of different ways that these sort of things are installed So they install routes whether it's your corporate IT department. This happens all the time, especially here in Europe Antivirus spot software or super fish which is by your OEM or say the country of Kazakhstan just proposed this for the entire country So they want to install a route so they can you know be the person in the middle Decrypt all your traffic and look at it and go go onwards and the way that works is they On the fly for just certificate that is trusted by your computer so This this is this is bad in itself But it also turns out that some of these proxies themselves don't validate certificates correctly upstream. So if someone was to Manipulate this that's not your proxy anybody can can create sort of a fake certificate And this is some a lot of the research around super fish found that this is the case oops Not only are you having ads injected into your supposedly encrypted streams Anybody on the outside can fake sites An extra bonus on this is if you install routes into your stores CAs that you trust They typically browsers will bypass these advanced techniques called key pinning. So if you Say for example in Chrome you they have a pre pre-computed list of sites And what certificates they should have if it turns out they see a certificate that's signed by One of these extra routes that was added by you know any one of these things then Keep hitting doesn't work anymore oops again so Trust trust is hard and and there's a lot of different ways in which in which it's been broken from bad code to bad infrastructure to just bad political organization of Who should get access to making these keys? Looking a little more deeply There's a bunch of different libraries that do crypto and as I mentioned here Almost all of these were affected by these validation bugs at one point or another in the last in the last decade So that's the client side. Let's talk about some issues on the server side and just just as a summary most websites use Apache Microsoft ISS engine X sorry not ISS IIS and engine X or say Google's internal stuff and And this mostly uses open SSL and you might have heard some things about open SSL lately, but I'll get into that Earlier in the decade or actually earlier in the last decade there was another library that was very common and it was by RSA and it was called be safe and be safe was one of the first robust SSL implementations and SSL implementations are all these crypto Things that I've mentioned require you to generate random numbers to generate these keys and I don't know if you've heard about this probably have but Dual EC DRBG it turns out there is a Random number generator that was standardized by NIST from the NSA That is almost guaranteed to be backdoor So even if all of your implementation is good if your random numbers that are using in your system are bad you can Work backwards and decrypt a stream So this was in be safe and it came up even re even the last couple weeks where in juniper Juniper screen OLS They had this dual EC DRBG although they changed the parameters to not the ones that the NSA knows but to the ones that potentially they know but Yeah, randomness is also you know another weakness to the system Heartbleed This is a big deal last year sort of but It turns out this is this is just another dumb bug in C, right? It's it's just an over read That ends up disclosing information on the server this one was really bad because there is another architecture problem in TLS servers, which is your private key is kept in the same memory space as Everything else and if you think of the way that people design security systems defense in depth this this is kind of absurd That the most exposed system that you have the web server What's actually being connected to by the outside world has in its memory space the keys to the kingdom the private key but Heartbleed just helped reveal this and and it was another big one that affected as I said almost everything uses Open SSL and it it was in open SSL for several versions So implementation bugs are fun, right? But it's it's it's fine people write code people mess up writing code There are formal verification methods or a ways to catch this but this talk is is about TLS and So TLS might be hard to implement correctly a lot of people made mistakes. What about the protocol itself? Turns out this has been Quite a disastrous couple years in terms of the protocol Let's this is the timeline of I guess TLS and SSL versions SSL one. I guess it's 1994 There's not really a lot of record as to when that happened, but SSL 2 came out in 94 99 was SSL v3 Then the IETF got their hands on it and turned it into a new protocol called TLS one which on The underlying if you look at the bits and bytes it's actually SSL 3.1. It's not that much is different There's a stronger definition of padding. I'll get into that later, but there's not not many things have changed Then down in 2006 we came up with TLS 1.1, which did almost again not very many changes It just made sure that in CBC mode. There's an IV. I'll get to that too and then TLS 1.2 1.3 is sort of coming up in the next in the next year It's it looks like okay, nothing can really happen these protocols all seem similar but in the meantime people have developed HTTP and and how the web is used for Sending information has evolved it back in say 94 web pages were just one static thing We didn't have cookies. We didn't have JavaScript. We didn't have all of these sort of fancy bells and whistles that are in the modern web so Turns out that HTTP is really great for enabling crypto attacks If you can Use you can you can do repeated plain text attacks. You can do chosen plain text attacks There's a lot of different things that HTTP allows you to do as long as you can get men in the middle access and As an attacker this is this is kind of how you do it if you are on the local network with somebody else then you can use ARP spoofing or some other method to get man in the middle position and You can inject random JavaScript onto unencrypted pages and with that JavaScript You can trigger the browser to send requests now in HTTP. There are some nice things like cross site origin policies that prevent Prevent you from from really doing a lot of different things But you can you can inject JavaScript into one page to make requests to another and the way that cookies work is they'll always be sent Even if the server has cross site request forgery protection You can still send cookies you can still sound requests and it turns out that if you can trigger errors in TLS Then the client will resend the same thing so it'll send you can send passwords anything that goes along you can kind of Put whatever you want in the URL and stretch this out do chosen plaintext things and what this allows is different Water-called oracles which is tools to as an attacker reveal the plaintext one bit or bite at a time and Compression oracles are I guess the easiest to explain in this HTTP in order to save space is compressed and Typically we use some algorithm like gzip or a dictionary based hash Sorry compression algorithm in which if you have two repeated strings, it's going to be shorter than if you do not have two repeated strings and That ends up being enough to allow you to decrypt an entire session if you can get the client to repeat so if You use something like this you can get a client to keep sending requests And you can as a man in the middle position you can kind of rearrange bytes and packets around But you can get the browser to keep sending requests with secret data in it you can't see inside the browser, but you can see the encrypted packets going past you and Crime and breach are these came out a couple years ago as practical very practical implementations of a Oracle for compression and in a practical sense This is this is kind of how it works you choose your padding and oops padding here is Anything at the end of the query string you control this you control the JavaScript So you can put whatever you want there you can get some padding and you want to guess the cookie So the point is you keep repeating the guesses until It matches the cookie and if you if your guess matches a cookie exactly then the message is going to be really small and If you look at this say say you're guessing One by day at a time if you have a bad guess It's probably gonna be longer and it's gonna be five compressed blocks And if you have the correct guess it's gonna be four compressed blocks So if you use your padding to kind of align yourself to hit the border between these encryption blocks You can go one by one Decrypting your values in this cookie and go all the way down to the to the bottom and and this is a practical attack That's been That's been pulled off. So crime is about TLS compression Everyone disabled TLS compression after crime happened breach came out the next year a black hat and This relies on HTTP compression which For performance reasons. Nobody has turned off. So crime is not really a problem now But breach is actually very exploitable in many many many websites Which is lamentable But compression is not the only way to have have an oracle Padding oracles are a kind of an older idea. They were originally Described by Vodney in 2002 and they rely on two really really bad choices that people made in deciding how to encrypt things in TLS and These are CBC mode and then the Mac then encrypt construction. So If you recall I don't block ciphers require you to have Certain number of blocks of data that go in certain and that same number comes out So for AES the most popular block cipher. We have 16 bikes come in 16 bytes come out. So I'm sure you've all seen the ECB penguin. It's It's the classic example of why CBC matters or why you need to do chaining if you if you only encrypt blocks on their Own and don't chain them together then you can actually see some cease if you have low entropy data if you have data That does that repeats the same kind of 16-byte blocks over and over again like images Then you can kind of make out what the images with CBC this is a way just of mixing one block into the next block and You just X or in the cipher text into the next plain text block and encrypt and this gives you a good amount of randomness all throughout your data and Decryption happens sort of the same way you start with this initialization vector and then you just X or the cipher text block into your Decrypted block and you go all the way down So this is this is CBC mode it it looks it looks fine, right? I mean this is this is something that is A good way to kind of combine crypto or so we thought in the 90s when this was invented Another debate that happened was if you want to have you need integrity and encryption So which do you do first you encrypt first and then you add an integrity tag or do you do integrity first and then add encryption? Somewhat disastrously they decided to do the integrity first and then encryption and for TLS it kind of looks like this there's a data HMAC and then padding and the data itself and Then that whole thing is padded up to a 16 byte boundary for AES or an 8 byte boundary for triple des but Up to the 16 byte boundary and then yeah encrypted so This HMAC is you have excuse me Mac the data with the header and the sequence number and That's and that that's gives you data that's authenticated and then encrypted but that padding there is not Authenticated which turns out to be a critical flaw Now in TLS or an SSL. What does that padding look like well? The terminal byte is the number of bytes of padding remaining and then it just has a bunch of garbage So you can pad things with zero and then it has zero bytes before it or one with one byte before it to whatever whatever and Then a TLS they updated that so that these bytes of padding have to match the original padding but Just having unauthenticated data is enough to give you what's called a padding oracle so if an attacker is able to distinguish between guessing a padding correctly or incorrectly that's enough to decrypt an entire message and technically how that works is if you are in a man-in-the-middle position You want to guess the last byte of data You modify the previous ciphertext block and you put in a guess and The way CBC mode works is that gets X-word in with the or decrypted block and you end up with M Which is the padding so? If you know that the padding is wrong versus right In the bottom case here, you know that the padding is correct because 0x 0 0 is a correct padding The h-max is going to be wrong because this is you're X oring some bad decrypted data into there, but You can work back backwards with this X or logic to Figure out what that value a is and then once you have a you can work back and figure out what the next value before it b is and All you need to do is to be able to tell as an attacker whether you're in case one or case two This padding oracle was originally Built into the protocol so there was this is the original vodna attack in 2002 you'd have a different error code for whether the padding was wrong or the h-max was wrong and as an attacker you try all 256 values for X and Once you guess correctly, it's going to give you the error code that says oh bad h-max meaning You got past the padding and you're you're and then you're right and you actually have decrypted one byte so This error this problem keeps coming back. There are Many many ways in which you can have side channels So the the error code side channel works is if you have an incorrect guess bad padding correct guess that h-max Later the next year Bonnet and Brumley came up with this timing side channel So it turns out that if you are have an incorrect guess then this is going to be fast because you're not doing the h-max and it's going to be slow if you Actually do get the padding correctly. So you just look at how long it takes for the server to do this can this computation and Voila, you have another padding oracle. You just might have to try to couple extra times to get rid of timing jitters But this lets you decrypt entire messages and in the context of HTTP This is your entire cookie or your password or something like this now This is all well and good, but as I mentioned things keep coming back and Patterson came out with lucky 13 This is two years ago, and it relies on a really kind of obscure fact about how this h-max is actually computed so As I mentioned before you can h-max it this this sort of 8-byte sequence number 5-byte header and your data and The the fix for this timing attack that happened was you just always h-max the whole thing if the padding is wrong you h-max the whole message and It turns out that in most implementations of h-max There's a lucky Byte there's there's a point in which the h-max takes more time than it would before there are different compression functions inside of it and if you're at 55 bytes It's going to be faster than if you're at 56 or 57 so if you have this is an entire 64 byte message which is just aligned on a four AES blocks and So what you can do is try to guess The padding and if you guess the padding wrong It's going to be a slow hash and if you guess the first body padding right It's going to be also slow but if you get really lucky and guess the last two bytes of padding correctly, it's going to be fast and Voila your two steps into your oracle attack and you can take this all the way down. So this this is found again This year a couple months ago in Amazon's new implementation s2n they created a TLS implement implementation from scratch what could go wrong and They tried to protect themselves from lucky 13 and ended up having the same sort of thing So if you look at it, there's this is a graph that a colleague of mine Filippo put together and trying to fix this in Go's crypto library which Sort of Presently Adam Langley who wrote it had a comment saying there's probably a timing side channel in this h-max And it turned out that yeah, yes there was and that was lucky 13 so I know another really really subtle thing that you would not have predicted in the 90s that came back to bite us and a really bad thing about this is that For TLS 1.0 and 1.2 that was the only way to use block ciphers is in CBC mode So unless you have both servers TLS 1.2, you're kind of screwed and that leads us to another idea which is the downgrade attack and The general philosophy around this is that if you support something old someone's going to trick you into using it and You know there's ways to defend against that, but it's it's really difficult to get right as a bit of a background The these are cypher suites, right? This is what SSL needs all these different things to this sort of alphabet soup to decide on what crypto algorithms to use and to break it down it's You have a key exchange certificate key transport cypher and then an integrity function and the server Gets a list from the client and it sort of picks its favorite from the list and then you know chooses it And if anybody was over at the next hall for the previous talk You'll know that there's something called export cypher's and these were supported for a very long time And this is to comply with this antiquated 90s crypto export law in the United States And these are really really weak cypher's so These were supported by clients and servers all the way up until this year. They still are and The fact that the server will always pick the best one of the client Everyone's safe right the server will always pick the best one turns out no These are several attacks that were described in the previous talk in which you can end up forcing clients and servers to use these really bad crappy crypto and The reason is it boils down to the only thing that's in this handshake. That's authenticated Is this key derivation stuff? so the pieces that you use to derive the shares shared keys and So this is what Freak is If you sit in the middle the client is gonna say hey, these are the cypher's I support you just change that list into Okay, I only support export cypher's and then the server say okay. Well, I support an export cypher to I guess we're gonna use this you must be an old client and Then all you have to do is crack that export key, which is you know 40 bits of encryption and and you're good Go from there or in some cases that you have to crack a 512 bit RSA key, which is also it's it's computationally doable The way that logjam works is very similar This works with RSA cypher suites This works with Diffie-Hillman cypher suites and this relies on the fact that You can force the client and the server to agree to use these Diffie-Hillman parameters to to do key exchange that are weak just old crypto small key sizes and You you crack it and then as a man in the middle you can manipulate and read everything Weak DH is sort of the same thing it relies on the fact that some servers use Diffie-Hillman parameters that were pre-computed and you can go kind of Three-quarters of the way through the attack because they're all using the same Apache Shared prime for this Diffie-Hillman stuff. So this relies on unauthenticated protocol in the handshake more on this to come in in The the theme of downgrade attacks poodle this turned out to be the nail in the coffin for SSL v3 You can Do this thing called the downgrade dance you can force browsers to to negotiate down from SSL from TLS 1.2 to 1.1 to SSL to at 1.0 to SSL 3 and As I mentioned before the padding in SSL 3 is just a bunch of X's and then a number So you can fill it in with anything so if you align your blocks so that the last block only has one Relevant bit of data you can do a padding attack and This when people came up with this they were just like Obvious obviously we can do this. This is terrible and SSL v3 is completely broken TLS poodle it turns out that I mentioned there's one change between SSL and TLS 1 One one one of the major changes is that that padding had to be defined as repeat the same padding value Well, some servers didn't do that. So You can end up doing the same attack in several Large percentage of websites are still susceptible to TLS poodle another threat to TLS agent crypto Yeah, I mean Diffie he's he's still doing well but This is sort of in the news now with with Different signature algorithms based on hash functions. This was presented back here at CCC in 2000 2008 some researchers were able to Forge one certificate from another by Finding a collision in this hash function that you use in the signature But this is kind of the details of it's a little complicated But they were able to make themselves a trusted certificate authority and issue certificates for everything And from that point onwards md3 md5. This is an old hash function had to be kind of booted from everything So how do how do all these attacks fit on the timeline? This is our TLS timeline as I mentioned These are the major attacks that I that I mentioned and they were really concentrated past TLS and this beast I didn't go into this but this is the first one of the backernum's so Attacks that you I forget exactly browser something something something. Yeah, you take a nice word and you make an attack name out of it but Down around Heartbleed. This is when the logo trend happened So every vulnerability had to have a logo and there's a really high concentration of these things around the last three or four years So as I mentioned if you can look here TLS 1.2. That was 2008 2012 nobody was using it This is from SSL pulse even 2014 SSL v3 was supported almost universally now. We're in a slightly better position but it takes a really long time for servers to upgrade and Same thing for clients right now We're seeing something around 75% of connections are TLS 1.2, which is great But the you can clap for that if you want but I TLS 1.2 solves most of most of these problems, but Most of these browsers they came out in 2003 2004 That implement it was at least five years later. So It takes a while for things to get up to date now This is this kind of paints a grim picture for these old vulnerabilities But at least from the ones that we've seen we can learn a few lessons And one is that if an attacker can identify one bit of information about the plaintext then it's basically over The way that HTTPS works Repeated data can be sent and you can take that one bit and expand it to an entire message There are side channels everywhere timing side channels computing side channels. There's been research about Working on in the cloud computing if you are able to do cash timing So if you're running one process and there's crypto hopping on another process, you can find out how long things are taking This is incredibly dangerous Almost all the things I mentioned having to do with Oracles relied on unauthenticated data and Having unauthenticated data doing Mac first and then encrypt leaving even padding padding is incredibly important And very and checking it correctly is it is incredibly hard. It turns out we've messed it up so many times, but AADs this is authenticated encryption with additional data. This is a construction that was introduced in TLS 1.2 ASGCM is sort of the most popular version of that We should definitely use those and just drop CBC altogether CBC is just a really really difficult crappy construction That hasn't service it serves service well to now But it's there's there's many ways to attack it and there will be many ways to attack it in the future X 509 the structure for certificates, which is ASN one These are really incredibly hard to implement correctly. There's there are at least nine years older than SSL itself these protocols and They're gonna cause you problems using this and As for downgrade attacks, you know support insecure crypto or protocols at your own risk because People will be able to somehow downgrade you to using them. So I skipped a lot of issues here TLS has had tons tons more issues. I mean beast. This is the RSA decryption Oracle s channel had a remote code execution bug a few months ago triple handshake Had to do I didn't even mention client authentication and how broken that is The whole CA ecosystem and certificate authorities messing up when it comes to issuing certificates didn't even go into that RC for weaknesses. Yeah, apparently this the stream cipher Patterson it around the same time as lucky 13 found you can decrypt an entire RSA an entire TLS stream if you use RC for There are vulnerabilities in big num libraries. There's issues with forward secrecy TLS is just absolutely loaded with problems from everything from the implementation side to the protocol itself So just enough complexity to hang yourself with Now I would say this is the end of the talk, but there's just one more thing I'd like to Just as a thought experiment go into some other Attacks that follow up what we saw in the last room so there's other negotiations that happened within TLS as As we talked about with freak and with logjam It's hey, which Diffie helman group do we choose or which cypher do we choose? There's also some other negotiations that happen. So there's NPN and ALPN These are protocols that allow you to upgrade to HEP to and then there's which which elliptic curves do I support? This is really interesting actually TLS supports a ton of kind of crazy elliptic curves and What if you did a downgrade attack on that? So this is a new kind of TLS vulnerability introducing called curve swap so this follows the exact same model as freak and logjam and What you do in a man in the middle position is you take the supported ciphers and you swap it with the smallest weakest possible curves supported by both parties and You put in make sure that it's a a curve that Sorry elliptic curve Diffie helman for key exchange So that both parties are going to be using these kind of smaller curves to derive their keys step 2 is this one's Bear with me. I'm really we don't know how to do this one yet, but solve this great log problem Hmm So, okay, yeah, yes, that's something that's not really doable right now, but on small curves It might be so but before we go into that Let's just think about what curves are supported in a TLS. There's there's some curves here called the sec t curves And this is a 163 bit curve Over it's a binary curve This is this is this is not the type of curve that we typically use but when elliptic curves were originally standardized for TLS It was all the rage. We had prime curves. We had binary curves They were both kind of equivalent and it if you look at the data and I did a survey of a lot of client. Hello's 4.3% of clients support this Kind of weak curve and this is this is about as strong as I think equivalent to RSA 1024 So Even though When you're doing a negotiation you expect to be using a really strong elliptic curve like a 256 bit one for their key exchange The men in the middle can downgrade you to This nice smaller curve and if as an attacker you can break the discrete logarithm problem on this curve Then for the Alexa top 100s 1.1 3% of sites Yeah, you can you can make them both use this really kind of crappy curve for key establishment But as I sort of as you guys have alluded to and you're chuckling Nobody's really broken DLP for any curves around this size They're the sort of largest curve that's been broken is 110 bits or so, but There's a reason we don't use binary curves anymore. They've kind of gone out of style there are Indexed calculus techniques that are supposedly better than brute sport brute force on these on binary curves So people consider them weak and we're not sure what kind of research has been done in private about say binary curves, so just The good news about this is That in TLS 1.3 the new standard all these curves have been excised So and there's a lot of these bugs have been kind of removed from the protocol itself But it's been a long and rocky road for transport layer security And that's the end Before we start to Q&A just a quick announcement if you're here for method is incorrect It's which to Sal G. So you should go there if you want to see it live There's going to be a stream in this room, but if you want to be there in person You should go there. I will give you Let's say 30 seconds to leave And Then please be quiet because we wanted to Q&A properly You can use this time to think of questions. We have lots of mics Two to their one there one on top and on the other side too and also if you're on the ISC on Twitter Ask questions. We have a signal angel that will read out your questions for us Okay, let's start at number one, please Hi Could you say something about Cloudflare strategy to not face or show one as Google and the others Yeah, I'd love to so as with any one of these protocols or types of crypto that Are broken or old once they're definitively broken or old They should be completely excised. So there's been a plan to Sunset Shah one let's say by the end of 2000 by the beginning of 2017 so the end of next year and The timing on which this this is to happen is is sort of debatable and There's there's really a question about whether or not Shah one is something that is a credible threat To happen within the next year or not or whether it's a credible happen threat to happen within the next five years in terms of forging a certificate so Whether or not you should continue to issue Shah one certificates or not. It's it's it's really something that It's a it's a big debate that's going on right now But if you compare to MD5 So now we have pre-start collisions, right? So and it took two years So one thing to keep in mind in this case and and I can go back to the slide about the MD5 collision is that Having a collision in Shah one is not enough to forge a certificate What you have to do is actually get the CA itself To predict a certificate that's created by the CA that aligns perfectly with the certificate that you want to forge And there are some techniques like putting randomness entropy into the serial number that can help defend against that, but Yes, there's a free start collision I don't know it could be it could be within the next month that we see a real shaman collision But in terms of colliding certificates, that's somewhat of a different story Internet please Thank you. Do you think we would be in a better shape today if SHTP had won the race over? HTTPS and why have you not moved to something like SPK I SDS I or any other alternative to PKI? well As speaking as part of cloudflare we control one side of the equation and as with any secure Security protocol you need both the client and the server to agree on what they're going to use So the evolution of the entire marketplace determines Which algorithms or which protocols you're gonna use and HTTPS ended up winning over the long term because it was most widely supported and As with any of these things. It's kind of a winner take all Number three please Yes, hi We clearly suck at implementing protocols, right? So we need to be able to upgrade stuff relatively Relatively rapidly because we will break it again and again and again. We'll need to upgrade Upgrading browsers is hard like I actually have to take an LVM snapshot before I upgrade my browser because I really don't know What's going to break? Why? Isn't any of the browsers going there out of GnuPG where basically there is a completely separate piece of software running in a separate process Communicating over standard in standard out and it's upgrade without touching any of the other system. Thank you So the question is Extracting TLS from the browser itself and putting it somewhere else so one of the the interesting things that Has happened in the TLS the HTTPS ecosystem is that many of the browsers are Actually doing that for this certificate validation. They're outsourcing that to the operating system itself Firefox is one of the loan exceptions that has their entire PKI stack I think it's it's historical reasons really I mean Chrome and Firefox auto update and they do so because They want to make sure that you have the latest and greatest things not They have kind of taken the approach that If your browser upgrades and it breaks Too bad for you. It's we know better and that's that's sort of that's their strategy. So I I'm not a browser vendor. I don't work for one of those companies. So I can't really Speak to what they want to do Number two Thank you You mentioned the defense in depth approach of separating the private key from the web server Now I know that cloudflare offers keyless as a cell which I really like Do you think that instead of just being a business advantage to you this could be a realistic? Security measure for many websites that they separate their private key to something behind a separate layer of keyless as a cell Yeah, I think this is this is something that could be more generally applicable And this is something that in the last IETF meeting they brought up So there's a proposal for separating private key operations from the TLS itself It was brought up as a RFC at the last IETF. So I would encourage you to check that out signal angel, please Frankie too wants to know whether IP version 6 encryption could replace TLS or mitigate at least some of these issues So IPv6 encryption Yeah, I think I don't see that as a replacement for TLS I see different layers of encryption whether it's TCP crypt or Anywhere lower down on the on the stack as Additional layers of defense in depth so The good thing about TLS is is that it encapsulates your HTTP messages and it's it's really just point-to-point on that on that side so It allows you to really trust the server itself whereas something like encryption at lower levels Yes, this is great I mean we have encryption on many different protocols Wireless, you know Wi-Fi is encrypted all of your sort of 3g 4g signals are encrypted More encryption is better and I don't think that having one encryption on a lower layer should stop you from adding encryption on a higher layer Microphone number four, please Hello, so you have shown how slowly the TLS standard itself is evolving and Even much slower the adoption is evolving and there would be my question Do you agree that we should heavily invest maybe even in the standard to make in easier Adoptable and do something more there and have you concrete plans or proposals how this could be achieved? I don't have any concrete plans or proposals on that, but I think it's a good idea I mean I think Upgrade ability is one of the one of the most difficult problems we're facing in terms of these protocols Because as you saw in all these different versions, there were problems and they had to be fixed in different ways And we're in say the Internet of Things the buzzword that we're all talking about these are embedded devices that are going to have one copy of a protocol and It's really hard to get firmware to be able to You know have a clean upgrade cycle, so it I Don't have any solution there But I see that as one of the biggest problems going forward in using protocols that are potentially insecure. Okay. Thank you Number six, please Hey, thanks for this nice set of reminders one thing I'm wondering when will you have any idea when TLS 1.3 would be like finalized and when I can finally actually enable it on my web server Not yet. I don't have a concrete date on that, but It should happen within the next year Thanks Internet, please Why is cloudflare using elliptic curve DSA even that is also relying on a very high-quality entropy of a pseudo RNG? so That's a good question as I mentioned Random number generation is very important for having secure cryptography and EC DSA or any sort of DSA based algorithm requires entropy for every signature or at least it did originally There's have been more recent RFCs on how to use EC DSA in a deterministic sense where you don't need a lot of entropy and Cloudflare has implemented that for our EC DSA. So our EC DSA is not using pure random numbers. It's Using a deterministic algorithm. So if we have a RNG collision, it's not a big deal for us Number one, please hi So after a talk of with like a string of calamities And depressing stuff, you know, I wonder if there are things that make you happy or optimistic About the future of TLS. It seems like, you know, we a lot of those attacks were just after Snowden So people are finally starting to pay attention You have things like the CA browser baseline requirements that were only finalized in 2012 Yeah, like once XP and Android 2 are dead, we'll have a shorter long tail like are the things that you're looking forward to or that are awesome about TLS Yeah, I think some some of the things that interest me and I'm excited by our Say that the my TLS project, which is formal formally verified TLS that I'm one of that I sort of glossed over was the triple handshake handshake vulnerability and that was discovered by formal analysis of it. I think The work that's happening in TLS 1.3 to just eliminate say bad curves or the RSA handshake all together are You know promising steps, but I think they could go a lot farther in terms of removing Things having to do with X509 and ASN1 and all these very old legacy technologies that we're carrying along with us My sorry if that wasn't too optimistic Number two, please What's your opinion just out of curiosity? What's your opinion on let's encrypt? I think let's encrypt is great and as much as much as I sort of railed on TLS in this in this conversation having an encryption of any sort is Preferred to not having encryption at all and the greater percentage of yeah, thank you I Think the greater percentage of the web that's encrypted the better and me personally I would be Absolutely over over overjoyed if we could get every site to be HTTPS only and that's Let's encrypt is a big part of that for for websites that can't use say cloudflare. We offer SSL for free Not everybody can use our services This is a great option for getting a free certificate Mm-hmm Could we please get two more questions so there's no point in standing up now. We just will finish what we started internet, please Suppose we have a customer that insists on still using SSL version three and we badly need this customer How to convince them to upgrade? How to convince them to upgrade that's a good question So there are people who have legacy systems right SSL v3 as we saw it was 100% adoption adoption on servers up until poodle came out so There are tons of different client libraries that only use SSL v3 what one example is Pingdom which is a popular tool to check if your website's online was using SSL v3 It actually upgrades at TLS once if the first connection fails, which we found out once we disabled SSL 3 but I Would I mean it's a it's a hard sell, right? I mean if you have a customer who wants to use a legacy protocol and it's only in use for specific clients that can't be upgraded then It's better than having no encryption So I don't really have a have a strong argument Microphone number two, please. Please make it short if you can sure Clouthers still seems to make life harder for tour users. When will this stop? Well, there's some people in the front row that I think you should talk to We're working on it. Okay, thanks. Okay, please once again. Thank Nick