 And the next talk is about the drone attack. It's secured, I said. It will be fun, he said, and smashed it with a compute hammer. Sebastian Schinzer has been interested in IT security since a long time. He's a PhD at the AFR Minster. And you may recall his talks back at 31, 28, or even 29, C3. Today, he will talk about the drone attack and how to attack TLS by making use of a server that supports SSL V2. Please welcome with an anniversary edition applause, Sebastian Schinzer. OK, so thank you very much for the introduction. It's great to be back. And I'm very glad that no one is leaving right now, because we're presenting a new vulnerability in SSL version 2. It's kind of old. The attack has a name, it has a web page, and it has even a logo. And having said that, I'm really glad that no one's leaving the room right now as well. The talk will be on breaking TLS. And so pretty much everyone here in this room uses TLS probably at this very moment while your mobile phone is checking whatever is going on on Twitter, Facebook, so over HTTPS, or you're checking your emails and stuff like that. So TLS is really important. The drone attack has 15 authors, and they obviously couldn't all come here. The six of us here is the most people that got on a single picture. And if you look closely, we are very happy to have received the first Pony Award for the best cryptographic attack in 2016. So we're really happy about this. But so when we talk about SSL version 2, what is really SSL version 2? So SSL version 2 was created in 1995, and it was immediately broken in 1995, right? So in the same year, just a few months later. So how did the internet look like during these ages? Pretty much like this, right? This is the internet of the 1990s with some cryptographic primitives like DES and RC4 and RC2 and so on and so on. Most of them are broken. And there's also some really interesting things like here export 40 bits, something like this, right? That's like a cipher primitive that was created because of politics, right? Cryptographic regulations in the 90s said that you're only supposed to export cryptography with a certain strength, with a certain maximum strength out of the US, and this is what we see here, right? So in 1995, SSL version 2 immediately died, and the reason for that is that the creators of SSL version 2, it was published by Netscape, they didn't authenticate the handshake. So an active man in the middle could just intercept the handshake and force you and the server, you as a client and the server to negotiate a very weak encryption. And there was no fix for that. This is nothing that you could fix off because it was a protocol issue. And so therefore in 1996, one year later, they came up with SSL version 3, which is still the basis on the protocol level for the TLS that we see today and that we use every day, right? So now you could say, okay, SSL version 2 was published in 1995 and it was broken in 1995. No one's ever gonna use this right now. Okay, I've got some data for you. So this is an internet-wide scan of the whole IPv4 internet in February 2016. And what you see here is not the amount of hosts, that's the percentage of all the TLS and SSL supporting systems on the internet. And there you see, for example, that 28% of all servers listening on port 25, which is SMTP, use SSL version 2, which is really, really strange, right? I'll come later to this point. What was the reason for that? And even for HTTPS port 4.3, we still see 17% of all the hosts out there directly support SSL version 2, which is really, really strange, right? So you could even say, right, these old dinosaurs all are coming back somehow to haunt us users on the internet, right? Okay, so to give you an overview, what is Drown all about? So Drown is a fairly sophisticated exploit chain and it will take me some time to explain all the puzzle pieces. So therefore, this is just a short overview of the requirements that an attacker needs to do in order to run a Drown exploit. So first of all, we can break one in 1,000 TLS connections. So not every TLS connection, but only one in 1,000. That basically means, so in order to break one of your TLS connections, the attacker on average has to collect 1,000 TLS connections from you. These can be connections that were recorded long before Drown was known, right? So we're not talking about an active attack, it's a passive attack, and so therefore just clicking record in your wire shark is already sufficient. And if you did this like on a Congress three or four years ago, you can break the TLS connections that you recorded back then, maybe under certain conditions right now. Okay, it doesn't come for free. So you need to perform two to the 50 encryptions, which is a lot. We can do this, but we need rather beefy hardware in order to do this. And there's one more requirement. We need to do around 40,000 connections to that server that supports SSL version two, right? So we need one server that supports SSL version two. And one very important thing is clients don't support SSL version two for very long time. So the last browser that supported SSL version two was Internet Explorer six on XP, right? And even Internet Explorer six would always prefer SSL version three, right? So if there's a way to negotiate SSL version three, it would also always use that. So we're really breaking TLS connections. So the connections that your very recent TLS client does right now under the condition that the same server is supporting SSL version two, which is really strange, right? So we break TLS using SSL. Okay, so we did an exploit and also we put a lot of effort into optimizing the attack. And the best thing that we could do was breaking a single TLS connection on Amazon EC2 for 440 US dollars. So which is pretty, right? So if everyone here gives like maybe 50 cents or so, that would be already sufficient to break a single TLS connection. So I don't need to break a lot of TLS connection. I just need to break a single TLS connection that your POP three client does every minute or so to get your email because there your password is in there. And if you get your password, right? We can break all the residual, right? So breaking just a single one is sufficient in most cases. Okay, I said there's a lot of puzzle pieces that we need to do and I try to cluster them to make them more digestible. So the first thing that I'm going to talk about is a special attack that I've already talked about two years ago. I will just go briefly into it. If you're interested more into the details of Bleichenbach's attack, just watch more from my talk in 31c3. I will show you a new protocol flaw in SSL version two and I need to explain what is it with 40-bit export ciphers. So when we combine these three puzzle pieces, we have a practical attack against SSL version two, which is not relevant at all because no one is speaking SSL version two on the internet anymore. We just have servers that support it generally, but usually we couldn't find any client that still negotiates SSL version two, okay? A second thing that we have to look at is shared keys among the different SSL and TLS versions. So when you set up an SSL server and it supports SSL version two, version three and TLS one dot zero up to one dot two, it will always use the same RSA key pair, right? And when we take this into account, all of a sudden, drown becomes a practical attack against many TLS servers, right? It's practical in an academic sense. It still means it's an expensive attack, but we can do it, right? We can afford it. We all here can afford it. And then we have two implementation errors. So all of the above practically means that we can attack every SSL version two implementation that is out there. Now here we're looking into two implementation errors in open SSL, and if we take, if we combine these with the already existing drown attack, we all of a sudden get a trivial attack, really trivial, that means it takes minutes on this laptop against a lot of TLS servers, right? Okay, so let's start with Bleichenbach's 1998 attack. And before I start with that, I just want to quickly repeat the RSA-based key exchange for TLS. So there's various ways of negotiating like a key. And when I say a key, it always means a symmetric key, right? So asymmetric encryption, for example, with RSA is pretty expensive. So therefore we just do the key exchange, like we exchange a symmetric key over RSA, which is not that, not that much data. And then the actual content that will be transferred over the SSL or TLS connection, this will use AES or triple desk or desk or RC4 or something like this. And what we are looking at is right now only the part where we negotiate this key for this symmetric encryption. So we have a TLS client, we have a TLS server. The TLS client always starts with a client hello and it contains a client random number. This will be like this changes with every request. So the client changes this number with every request and it will be sent in clear text. So the attacker knows this. The second message, the response of the TLS server will be the server hello. It will generate a random number as well. It's a server random. And this will also change with every new connection and it's also sent in clear text. So the attacker knows client random and server random. And then it also sends this certificate that you buy for Komodo or at Komodo or even at Let's Encryptor, so you get it for free. And in this very certificate, there's an RSA public key. Right? And this RSA public key will be also sent with a certificate and with the next message, the client key exchange, the TLS client generates a thing that is called a pre-master secret. And this is the only part that is really secret in this whole exchange. It will not send this pre-master secret in clear, but it will encrypt it with RSA and the key from the certificate that it just received from the server and sent this over. In the next step, and this is a very important step, the TLS server decrypts the pre-master secret that it just received and from this pre-master secret, both the client and the server can generate the same symmetric key, okay? So that means the attacker knows the client random, it knows the server random, and it gets an encrypted version of the pre-master secret. And if the attacker can decrypt this pre-master secret, he knows the master secret, the symmetric key that is used for RC4, IAS and stuff like that, right? So this is the holy grail that we want to break right now and Bleichenbach's attack achieves exactly this, right? So that's important. What I need to mention here is this decryption can fail. So when the attacker sends, let's say, an arbitrary ciphertext, some junk data or so, the server first has to decrypt this ciphertext in order to find out whether this is a valid pre-master secret or not, okay? So in order to conduct the Bleichenbach's attack, we need an oracle. So that's a cryptographic term for nothing else than a service that accepts an arbitrary ciphertext and it will decrypt this ciphertext so it needs to have the RSA private key and it responds with one or zero, so true or false, depending on the successful decryption, right? So if the decryption was successful and the pre-master secret looks somehow valid, right? Looks somehow, then it will say, okay, it's true or otherwise it's false. So we only get one bit of information from this oracle. So we have a client here and a server. We have an attacker that eavesdrops on this connection and then it changes certain parameters of this connection and sends it over to the oracle. The oracle decrypts it, parses it and then says, okay, decryption was successful or not. That's the only information that the attacker gets from the oracle. So every time the oracle answers with a one or with true, the attacker learns a tiny fraction of the RSA ciphertext. So there's a mathematical formula where you could put everything in and if the attacker only does this, let's say a few thousand times or so, he can learn the full ciphertext. He doesn't get the RSA private key. We only get like, we only can decrypt this single RSA ciphertext. Okay, so in the original paper of Deichenbacher from 1998, he was exploiting the fact that common TLS implementations would like, they had like an explicit error message for this type of decryption failure. Which is really bad. And so they didn't actually fix the SSL or the TLS standard. They just said, okay, here's an implementation fix so that the Deichenbacher attack won't work anymore. And it works like this. So we pretend that the decrypted pre-master secret that we have received was correct and we proceed with a random pre-master secret. So in case that the ciphertext that we have just received was in mallet would just generate a random pre-master secret and continue with the flow. And this will obviously lead to some later error because the symmetric key that comes out here is different for the client and the server. So they simply speak with a different key and can't decrypt each other and then it comes to an error. So this looks like this. So the server will decrypt the pre-master secret. He will always generate a random pre-master secret and then depending of whether the decryption succeeded or not, when it succeeded, it will proceed with a decrypted PMS. In the case where the decryption failed, it will proceed with a random pre-master secret that it just generated. And so this makes all the implementations that we looked at like it's indistinguishable whether the decryption succeeded or whether it failed. So it's an implementation fix that is written in the RFC. Now we exploited this very countermeasure for Bleichenbach's attack in order to conduct a new Bleichenbach's attack. And it works like this. So let's look at the SSL version 2 protocol. It's slightly different from SSL version 3, but it doesn't really matter here. So we also have a client hello. We also have a server hello. We also have this kind of client key exchange. It has just a different name, where we send this symmetric key that was generated by the client and then both would generate the symmetric keys. And what is interesting here is the first one that responds with an encrypted message will be the server. And this has one very important implication. That means the client gets one ciphertext. So the server verify is an encrypted message with a key, so with that master key that both client and server should know by now. And the client gets this message without proving that it has the same symmetric key. In SSL version 3 and in TLS, this is different. So this message here will only be sent after the client proved with a finished message that he possesses the same symmetric key. So the attacker gets one ciphertext that is encrypted with an unknown key, because we don't know the key yet. The question, and please accept it, that this is now an important question that we need to raise, and I'll explain it in the next two slides. Can we learn this key? So we get a ciphertext, and the question is can we learn the key that was used to encrypt that message? Now, when we look at the specifications of SSL version 2, we learn that there are so-called export ciphers that only have 40 bits of strength. So this is how a cipher suite looks like, and it keeps on looking like this. It always has the same format. It tells us there's a symmetric key algorithm that we use as RC2. It uses 128-bit keys. It uses a CBC as a mode of encryption. And it uses export 40 with MD5 as an hash algorithm. So that means we have a 128-bit key, but only 40-bit of those are encrypted. I told you the client generates the symmetric key and encrypts it with the public key of the server and sends it over. And here it doesn't fully encrypt the 128-bit, but only the 40-bits. Only 40-bits will be encrypted, and 88-bits are sent in clear, so everyone can read it. And in the 90s, the Clinton administration did this regulation. They said, OK, so 40-bit is enough to protect people with online banking stuff and so on and so on. But obviously, the US government wanted to look into the SSL connections of whatever country this cryptographic code will be exported. When you look at the implementation, the master key will be built in a way that the clear-bits, the 88-clear-bits, will be concatenated to the decrypted 40-bit secret keys. And obviously, for non-export ciphers, so you get the same cipher suite without the export 40 here. For non-export ciphers, the length of MK clear, so the bits that are sent in clear, is zero. OK, fair enough. This is maybe not the best idea to do something like this from a politician's viewpoint, but still, OK, it makes sense, at least in the 90s. OK, so let's look at this server verify, this single message that we get and where we want to know the key. When we look at the specifications, we learn that the server verify is nothing else than the client random that it sent us in the client hello. So we know the clear text, because it was sent in a clear, and that was encrypted with a master key. So we know the plain text, and we know the cipher text. And we also know when we negotiate this with a 40-bit export ciphers, which we can do, then only 40 of those bits of this master key are secret, which means we can do a brute force search for the key. We know the plain text, we know the cipher text, then we can look for the key, because there's only two to the 40 possibilities of the key size, which takes on beefy hardware a few seconds or a few minutes. But you can even do it on this laptop, and maybe finish it in a day or so. So this is nothing really critical. OK, so let me show you why this is important and why this forms a new Bleichenbacher oracle. So let's assume we create a new cipher text, a new encrypted premaster secret using export 40 bits, and send it to the server, and we do it twice with the same cipher text. Then we get two server verify messages, and we break the key that was used to create the server verify messages. In case that the premaster secret was correct, we follow this path. There we proceed with a decrypted PMS. And as we didn't change the cipher text, the premaster secret is the same, so therefore the master secret is the same, so therefore we get the same master key. In case the premaster secret is invalid, we follow this path here, which means that the master keys for both server verifies will be different because it will be generated and a new premaster secret is generated for each and every request that comes in. And this we could distinguish. So this forms a new Bleichenbacher oracle with the only condition, so we don't get any error messages from the server, right? Everything is correctly implemented as in the RFC, but if we send two cipher text, the problem here is so when the server verify, the key to generate the server verify was the same for both messages, then we know it was invalid, otherwise it was valid. Okay. So when we had this and it was a much larger group that came up with this attack, so we had a practical attack against SSL version two. And now you need to imagine like a bunch of academics in their ivory tower, you know, like high fiving, yeah, we did a new attack, a new cryptographic attack, but it has zero relevance, right? So we were missing each other, something like this, right? Okay. So we need to look further, that's not sufficient, okay? It's a cool academic attack, but it's not relevant at all for the internet. So let's look at how people use SSL and TLS, how they configure it. When you set up a new server using Apache or Engines or IIS or whatever, at least to my knowledge, there's no way of saying if a client comes in and he connects using TLS 1.2, then he gets key A and when he connects with SSL version three, he gets a different key. That doesn't seem to be possible. So that means when you set up a system with a key pair, they always use the same key material. It's always the same RSA, public key and private key pair that will be served independently with a protocol version it is, okay? So that's an important insight. What is also very interesting is, a valid question would be, will people use the same TLS certificates for different protocols? So are there people out there that buy a certificate or get a certificate from Let's Encrypt or so and use it for HTTPS, for SMTP, for IMAP, for POP3 and all the different other ports? And it turns out they do, okay? Which is a problem because everyone is looking at the secure configuration of HTTPS, so everyone is looking at HTTPS and no one really is looking at the security of the TLS configurations of IMAP, POP3, SMTP and so on and so on. So which leads to the fact, I said Bleichenbach's attack works against RSA ciphertext. It's nothing written that this is specific to a specific TLS version, it's a generic RSA decryption oracle, right? So which means if we have 10 systems and these 10 systems all share the same certificate and only one of those 10 systems is vulnerable to drown, then the connections to all 10 systems can be broken because it's a generic RSA decryption oracle. So it works like this. This is pretty clear, right? So when we have a server and it accepts TLS connections and SSL version two connections, then an attacker can eavesdrop on this TLS connection, record it and use this server as a Bleichenbach oracle over SSL version two in order to break it. So there, so if a system supports SSL version two, all the TLS connections that go there can be broken as well. That's pretty clear. What is new here is, let's say we have two servers and both use the same RSA key material, maybe the same certificate or even the same certificate, truly or a different certificate. So what we saw with Heartbleed was the Heartbleed attack would compromise the keys. So using a Heartbleed attack, an attacker could learn the private key of that TLS server. So you had to apply for a new certificate, you had to buy a new certificate. What many people did is they used the same RSA key pair that was compromised in a previous certificate and bought a new certificate with the same keys that was compromised before, right? Which is not a very good idea. Okay, so it could even be that both use a different certificate but have the same RSA key pair, right? We saw this on the internet as well. So in this case, let's assume this server here doesn't support SSL version two, so it's not directly vulnerable to drown. The attacker can steal eavesdrop on the TLS connections that it sees here and breaks it afterwards by making SSL version two connections to this server, which uses the same key material and supports SSL version two, right? So, and when we scan the internet how this affects the amount of hosts that are vulnerable to drown, this was pretty dramatic. But before we look into this, let me just not go through all the numbers that you see here. I just put on all the numbers that you see that it's really a substantial amount of RSA key pair sharing on the internet. So you have to read this table like this. For all the SMTP servers, we collected the TLS certificates and then looked where did we see this public key in maybe a different certificate or the same certificate on some other port. And there we saw, for example, from all the TLS certificates that we encountered on SMTP, 30% we found on IMAP. I know that's pop three. 29% we found on IMAP and so on and so on. And so what is really interesting here is people seem to share a substantial amount of keys across protocols, which is pretty substantial. This is very interesting here. So when you look, for example, for HTTPS, so a lot of servers on HTTPS were vulnerable. But as I said, HTTPS, many people look at the configuration of HTTPS. No one seems to care about the TLS configuration of SMTP. It's even like this that people say, for SMTP, if you can't negotiate a TLS connection, if you can't negotiate a TLS connection, it will fall back to plain text. So for SMTP, bad encryption, bad cryptography is better than plain text, right? But what we have here right now is when people have a bad SMTP TLS connection and use the same key material for HTTPS, we can break your HTTPS connections by exploiting the weaknesses in your SMTP configuration, which is pretty substantial. So when we look at the numbers, this, in most cases, it doubles. So we had, let's say, for port 25, 28% of all the SMTP servers that support encryption on the internet were vulnerable to drown. Now when we extend this attack and say, okay, we have the system here and we want to attack it, the system itself is not vulnerable to drown, but the public key is used on some other system on the internet on a different port, we can do the attack there. And this here means that 50% of all SMTP servers encryption-wise can be broken for port 43, for example, it's one-third of all the internet that support encryption. We could break TLS connections to these systems by exploiting some other system that happens to use the same RSA key pair and supports SSL version too. That's a really substantial effect that we encountered here. Okay. So I said that drown itself is not a cheap attack. So it's actually quite complex and we thought about how can we make efficient attacks for drown. We need to do this like, so we need to perform two to the 40 exhaustive searches, so encryptions or decryptions and we need to do this for around 1,000 oracle queries. All right, so that's a lot, two to the 50. And so we basically took the code, we took some code parts of OpenSSL and did a naive implementation using the RC2 code and the MD5 code of OpenSSL. That was the naive implementation of everything. And there we had like, okay, for the full attack, it would take us something like 50 days or so, which is pretty long and we wanted to be better. Then we asked the people from Hashcat. So the Hashcat team, one of the authors of Hashcat is also a co-author of Drown. And so we sent him the code and asked him, can you help us? Because it is pretty similar to password cracking, what we're doing, right? Drown is pretty similar to cryptography-wise with password cracking. And then he took the code overnight and made something like a factor 30 or so improvement to it, which is really like, okay, this is crazy. Absolutely stunning, right? And so we ported this on Amazon EC2 and found out that for the cost of $440, we could break one TLS connection in eight hours. So this is a pretty substantial improvement. Okay, cool. So now we have a practical attack against many TLS servers. And this is like the Drown attack that works against every SSL version 2 implementation out there. Now we have two implementation errors in OpenSSL, which are interesting enough so that we have to show them because they make Drown really, really easy. The first one we dubbed it Cypher Suite Selection Buck. It works like this. Before we can understand this bug, we need to understand that there is, when you do SSL configuration or TLS configuration, you always have a protocol version and you have a Cypher Suite. And with every new protocol version, there was a bunch of Cypher Suites released, right? And so what many people did is they always configured their Cypher Suites. So they said, okay, we only used the secure Cypher Suites and then we disabled the ports of here, for example, we disabled SSL version 3 in order to prevent the Poodle attack. But SSL version 2 was not explicitly disabled, right? Which meant the OpenSSL behind that, it would enable SSL version 2, but there was not all the export Cypher's would be forbidden, right? So this Cypher Suite configuration here would forbid export 40 bits Cypher Suites. So therefore Drown shouldn't work, okay? So how does like SSL version 2 do the Cypher Suite negotiation, right? It works like this. In the client, hello, the client asks, hey, server, do you want to talk with export Cypher's? And the SSL version 2 would respond, sorry, I don't do export Cypher's, right? And then the standard compliant SSL version 2 client would say, okay, oh, too bad, okay, bye, see you next time. Or maybe try another protocol version or so, something like this. Now this is the relevant code that will be used afterwards, after the handshake that I've showed you right now. So let's just assume the client wouldn't say, okay, bye, sorry, it's really bad that we can't talk exports. So if the client says afterwards, okay, I wanna talk export anyway, let's have a look what the code does. So here we receive the data from the network. This is like this, this is that message that contains the encrypted pre-master secret and that also contains the Cypher's suite that the client just selected. It will get the SSL Cypher's suite by that char that came in. So each Cypher's suite has one byte or put it differently. So there's a byte that denotes a certain Cypher's suite and this function will just get a pointer to this particular crypto code. If this was not successful and not successful means the Cypher's suite was selected that is not compiled in, okay? And if it is compiled in, it will simply be used. So who sees the part that checks the configuration? So we haven't certainly found it, right? So it's not there, okay? So basically what happens is a non-standard compliant SSL version two can force that handshake. So we say wanna talk export Cypher's? No, I don't do export Cypher's, sorry. Okay, we go, right. Okay, let's talk export 40 anyway and we would say, okay, sure, we can do that. Sure. So the story behind here is like this. Nimrod did this use SCAPI, a very bad SCAPI implementation of some kind of a scanner in order to look how many systems on the internet supported SSL version two and I did the first scan and I found like this huge amount of numbers of SSL version two scanners and then I used a different scanner that just looked for SSL version two and it would say no, SSL version two is not supported. And I debugged and I debugged and I debugged, this took us weeks and then I saw that Nimrod was just too, he was simply too lazy to parse this message. So he would just say, hey, wanna talk export Cypher's? Yeah, yeah, yeah, let's just talk export. But he didn't just care what the server was responding and so this took us, yeah, so we were lucky, okay? If we didn't have this implementation bug, we probably wouldn't have found many of those, we wouldn't even have found this bug. So independently of your SSL configuration, of your Cypher suite configuration, using this bug against OpenSSL, we can negotiate whatever we want over SSL version two, okay, but using a non-standard compliant SSL client. Okay, so this means the server is vulnerable to drown and this is even though you disabled SSL version two export Cypher's, which is cool. The second one is a special drown and this is really, it's really very special. It's also an implementation flaw. It's not a, it's an implementation flaw. So let's again use this Cypher suite. So we use RC two with 128 bit keys, but we transfer all except the 40 bits in clear. We have talked about this before, right? An implementation flaw allowed to use these clear bits, so the bits that are sent in clear with non-export Cypher's. So for non-export Cypher's, we said MK clear needs to be zero. This is not the case here. So a standard conforming client would like, so for a non-export Cypher that we have here, we would use all the 16 bytes. So the 128 bits would be filled with the secret part that we just extracted from this encrypted pre-master secret. Okay, if we send four clear bytes along with a 16 byte pre-master secret that was encrypted, it will still prepend it to the actual encrypted pre-master secret. So that means K13, K14, K15 would simply fall off, okay? Which becomes really interesting when we send 15 clear bytes. Because then all of a sudden, we have a server verified that was encrypted with a 128 bit key where we know all but one byte. And then we can brute force on average 128 encryptions, right? So, and now we do this like in a stepping mode, right? So we send 15 zero bytes as MK clear. We break the Cypher text, we learn K1. In the second step, we send 14 zero bytes. We know K1 from the previous step, so we brute force K2. In the next step, we send 13 zero bytes, we know K1, we know K2, we want to brute force K3 and we do it, right? And then like for this case where we send zero bytes, we have learned K1 to K15 and only have one byte and we need to brute force it, it's again 128 bit, right? Okay. So that means, so we dub this special drown because it's a special version of this attack. The generic drown still has two to the 40 complexity per oracle request and we need to have something like 1,000 oracle requests, so it's pretty substantial. But this two to the 40 in case of special drown goes down to 15 probe connections and all together approximately less than 2,000 trial encryptions. So this can be done with it, the full attack can be done within a few minutes on just a normal Linux laptop, right? Which is very, very critical. So what is interesting here is this bug has been fixed by an OpenSSL developer without knowing that it was fixed. So Nimrod and I, we submitted a bug that was totally unrelated to drown. We didn't even know drown. This is like one and a half years ago or so. And OpenSSL did a patch and they patched this bug without knowing what it actually was. So it wasn't really a silent fix because no one was really noticing what was going on here. But later we figured out that this is pretty substantial. Why I'm explaining this to you is we can scan again the internet for this. And we can look at who didn't patch their OpenSSL when we submitted the patch like one and a half years before. And so this here means this is the amount of internet hosts that run some kind of encryption and that use OpenSSL that is more than one year old. So these people don't really patch. And when you compare this to the amount of servers that are vulnerable to drown, you will see that most of them are OpenSSL actually, because the numbers are very similar. Okay, so in summary, there's just one sentence that I can say that is very, very important. One sentence that I can say here, ancient SSL version two breaks current TLS. And we can do nothing else than just disabling SSL version two, right? It's dead for good. But an important discussion is also, who's to blame for drown? So what was the fault here? So the first one is pretty obvious. So we have some crypto design flaws were done in the 90s. Okay, that's nothing that is really too surprising, okay? 20 years ago, many things happened between them. We have some crypto implementation flaws from the 90s. And like the OpenSSL guys were like, okay, I've never looked at SSL version two code. It's been there forever. Nobody has looked at it. And so it's really old implementation code. What is more a problem is the crypto configuration flaws. So people were configuring their SSL servers in a pretty bad way. And what is also quite interesting is the export ciphers, export 40 bits is a thing is an essential part to drown. So drown wouldn't be a practical attack if we hadn't the Clinton administration who forced this crypto regulation that only export cryptography may only have like 40 bits in secret. Okay, so what are the mitigations for the administrators here? So disable SSL version two and SSL version three while you're at it, right? Because it's also, so SSL is insecure, right? Don't use the word SSL anymore. TLS is the real thing, okay? And then obviously update your OpenSSL regularly, which is a thing that you should do for every library that is in some kind of security element, okay? So this is the mitigation for the admin. The mitigation for the citizen in my opinion is vote against crypto backdoors, right? Thank you very much. Thank you, Sebastian. Do we have questions from the audience? Okay, we have one question, I think. We start with microphone three please. Yeah, actually it's two questions. One is how specific this is for RSA? I mean, would it work also for Diffie Helman based crypto? And also after the hot bleed, a lot of people start looking into the OpenSSL code and even forks started and so on. So has the situation improved since then? So the first question was, is it limited to RSA? Yes, it is somehow. We can impersonate the server with like, when we have substantial hardware, we can impersonate the server simply. It's hard to explain like this without slides for this. So look at the paper. So we have broken quick using this. We can break Diffie Helman, but this is not an offline attack, it needs to be an active man in the middle, okay? So it's your first question and it's limited to RSA. Yeah, so for example, yeah, so Diffie Helman doesn't work. And your second question was, excuse me? If the situation is OpenSSL or other SSL implementations has improved since hot bleed. Okay, so this bug hasn't popped up in one of the audits, probably because people didn't care about SSL version two because it's already messed up, right? So people were doing a focused audit, which is what I would expect. They did a good job there. Okay, thank you. Do we have questions from the internet? No, okay, microphone one please. More of a note, when you say you have to update your OpenSSL regularly, something that's important is that you actually restart all your services because if you just update your OpenSSL implementation, all the running processes are still linked against the old version, that's a deleted file, and you're still vulnerable unless you actually restart every single one of your services that links against OpenSSL. But there goes your uptime, right? 1,000 days uptime, yeah, yeah. Thank you, microphone four please. You mentioned that there's a factor of 1,000 that you have to apply to the 20 to the 40. Where does that come from? I think I missed that. It comes from Bleichenbach's algorithm, right? So when Bleichenbach's algorithm from 1998 was published, it was dubbed the Million Questions Attack because you used to have to send like one million, on average one million messages between client and server in order to decrypt the ciphertext. This has changed dramatically in the years between. So there are several papers that did improvements to the attack and now it's boiling down to a thousand approximately. It depends on the size, it depends on the pre-master secret, but on average 1,000 connections is what we need, okay? Thank you and the next question is on microphone one please. This is just a paranoid question about if you're using the OpenSSL library, when you said disable the protocols, I presume that means when you do the function call where you pass in no TLS version or no SSL version, there's no SSL. Has someone checked that they're actually checking that? If they're not checking the protocols, if they're not checking the cipher suites rather, are we guaranteed that doing that means you're protected? Can I, if I've said no SSL v2 when I set up the context in the library, does that mean I can breathe easy? So OpenSSL deleted the SSL version 2 code after we told them about it, so it's fine. Just update OpenSSL and you'll be fine. It will be deleted. It's not there in the repository anymore. That's what I wanted to hear. And restart your server. Your, sorry, a service. Microphone five in the back please. Yes, thank you. I wanted to ask, have you looked into other crypto libraries except OpenSSL? Yeah, so most of the modern crypto libraries, so with modern, I mean, the ones that appeared in the last few years, they didn't implement SSL version 2 at all anymore. So Libre SSL, for example, they just deleted the code, boring SSL deleted the code, like the Python libraries and so they didn't even implement it and so on and so on. But all the ones that were, that we looked at, for example, the code that is in IIS, S-channel, it has, it still supports SSL version 2 and it has the same protocol flaws. So if you support SSL version 2, you're vulnerable, independently of the implementation, at least how we looked at it. Okay, thank you. Welcome. And I think microphone one please. Why the name Drown? That's a good question. So there's, I think, so Nimrod came up with the initial idea and he has this, like his favorite movie where this plays a role and then we did a background which I don't remember anymore. It's written in the paper, sorry about it. I don't even know the background anymore. It's just a working name and then it got viral and yeah. And of course, more information is provided on the FAR plan. So any other questions? Okay, in this case, I have a question. Usually you say, okay, which politician was it that said, okay, please weaken the strength? The security? The SLV2 security? I'm sorry, I don't get the audio here. Oh yeah, of course the audio on the stage is not that good. Let's say more than in general information. We have the politicians that try to weaken the security. So which one was it again? This was the Clinton administration. But this is not to, I mean, every politician obviously wants to do this because of terrorism. Yes, of course, because you're all that bad people. Yeah, and so if we do this right now, if you have crypto regulations right now, we at least make sure that maybe in 10 years, maybe five years, maybe 15 years, we have another bunch of crypto PhD students who can write their PhD thesis on it, how to break them, right? So that's maybe one good thing about it, but in general, it's not a good idea. Okay, any other questions in the meantime? I think microphone five, is this a question? Nope, he says just down. Oh, there's a question. No? Hi. Four please. You said that for mail servers, it's still a good idea to support old crypto. So with a drone attack, it isn't anymore I expect or did I misunderstand? So there's an argument of supporting SSL version three, even though it's broken, but it's broken in a sense. So the poodle attack is still, it's obviously more effort breaking SSL version three than reading the plain text, okay? With the drone attack, it's different because even when you use secure TLS connections, you can still break it by exploiting SSL version two. So and the word for this is opportunistic encryption. So some bad encryption is even better than no encryption and this changed for drone. And I think this is the first attack where this works cross protocol. But don't you compromise, oh, you don't compromise your RSA private key with drone. Okay, yeah, then I get it. So you don't need to buy new keys for it, right? You can still use your same key, just remove SSL version two from your configuration and restart the server and you're fine or update open SSL. Okay, any other questions? In this case, please give an anniversary edition applause to Sebastian Schenzer. Thank you very much.