The DROWN Attack
Schinzel, Sebastian
We present DROWN, a novel cross-protocol attack on TLS that uses a server supporting SSLv2 as an oracle to decrypt modern TLS connections. Using Internet-wide scans, we find that 33% of all HTTPS servers are vulnerable to this protocol-level attack.
 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 FHAR Münster. 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. [? APPLAUSE?] 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 V2. It's kind of old. The attack has a name, it has a web page, and it has even a logo. 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 like 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 V2, what is really SSL V2? So SSL V2 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 V2 immediately died, and the reason for that is that the creators of SSL V2, 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 V3, 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, OK, SSL V2 was published in 1995, and it was broken in 1995. No one's ever going to use this right now. OK, I've got some data for you. So this is the 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 443, 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, these old dinosaurs all are coming back somehow to haunt us users on the internet, right? OK, 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 has, 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 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. OK, 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 2. So we need one server that supports SSL version 2. And one very important thing is clients don't support SSL version 2 for very long time. So the last browser that supported SSL version 2 was Internet Explorer 6 on XP. And even Internet Explorer 6 would always prefer SSL version 3. So if there's a way to negotiate SSL version 3, it would also always use that. So we are 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 2, which is really strange, right? So we break TLS using SSL. OK, 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. So which is pretty right. So if everyone here gives maybe $0.50 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 POP3 client does every minute or so to get your email, because there your password is in there. And if you get your password, we can break all the residual. So breaking just a single one is sufficient in most cases. OK, I said there's a lot of puzzle pieces that we need to do. And I tried 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 look at what's more from my talk in 31c3. I will show you a new protocol flaw in SSL version 2. 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 2, which is not relevant at all, because no one is speaking SSL version 2 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 2. 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 2, version 3, and TLS 1.0 up to 1.2, it will always use the same RSA key pair. And when we take this into account, all of a sudden, Drown becomes a practical attack against many TLS servers. It's practical in an academic sense. It still means it's an expensive attack, but we can do it. 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 2 implementation that is out there. Now, here we are looking into two implementation errors in open SSL. And 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. OK, 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 a key. And when I say a key, it always means a symmetric key. So as a metric encryption, for example, with RSA is pretty expensive. So therefore, we just do the key exchange. We exchange a symmetric key over RSA, which is 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 des or des 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 metric 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. 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 send this over. And the next step, and this is a very important step that 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. 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 the pre-master secret, 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. So this is the holy grail that we want to break right now, and Bleichenbach's attack achieves exactly this. 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. OK. 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 1 or 0, so true or false, depending on the successful decryption. So if the decryption was successful, and the pre-master secret looks somehow valid, looks somehow, then it will say, OK, 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, OK, 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 1 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. OK. So in the original paper of Deichenbacher from 1998, he was exploiting the fact that common TLS implementations would like, they had 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, OK, 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 Mellet, we'll 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. OK. Now we exploited this very countermeasure for Bleichenbach's attack in order to conduct a new Bleichenbach's attack. And it works like this. OK. So let's look at the SSL version 2 protocol. It changes. 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 their 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 like 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-bit 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 0. OK, fair enough. OK, this is maybe not the best idea to do something like this from a politician's viewpoint, but still, OK, it makes sense. OK, 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 Blaischenbacher 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 Blaichenbacher oracle with the only condition. So we don't get any error messages from the server. Everything is correctly implemented as any RFC, but if we send two cipher texts, 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. 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 2. And now you need to imagine a bunch of academics in their ivory tower, like high fiving. We did a new attack, a new cryptographic attack, but it has zero relevance. So we were missing each other, something like this. So we need to look further. That's not sufficient. 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 NGINs 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 3, 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. 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, 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 a specific TLS version. It's a generic RSA decryption oracle. 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 looks 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 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, which is not a very good idea. So it could even be that both use a different certificate but have the same RSA key pair. 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. When we scanned 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. No, 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, 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, it will fall back to plain text. So for SMTP, bad encryption, bad cryptography is better than plain text. 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, 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, OK, 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 1 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. OK. 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 2 to the 40 exhaustive searches, so encryptions or decryptions. And we need to do this for around 1,000 oracle queries. So that's a lot. 2 to the 50. And so we basically 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, OK, 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. 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, OK, this is crazy. [? Applause?] Absolutely stunning. 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. OK, cool. So now we have a practical attack against many TLS servers. And this is 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 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. And so what many people did is they always configured their Cypher Suites. So they said, OK, we only use the secure Cypher Suites. And then we disabled the ports. So here, for example, we disabled SSL version 3 in order to prevent the Poodle attack. But SSL version 2 was not explicitly disabled, which meant the OpenSSL behind that, it would enable SSL version 2. But there was not all the export Cypher's would be forbidden. So this Cypher Suite configuration here would forbid export 40 bits Cypher Suites. So therefore, Drown shouldn't work. So how does SSL version 2 do the Cypher Suite negotiation? 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. And then the standard compliant SSL version 2 client would say, OK, too bad. OK, 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, OK, bye, sorry. It's really bad that we can't talk exports. So if the client says afterwards, OK, I want to 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 premaster secret, and that also contains the Cypher Suite that the client just selected. It will get the SSL Cypher Suite by that char that came in. So each Cypher Suite has one byte, or put it differently. So there's a byte that denotes a certain Cypher 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 Suite was selected, that is not compiled in. 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. So basically what happens is a non-standard compliant SSL version 2 can force that handshake. So we say, want to talk export Cypher? No, I don't do export Cypher. Sorry. OK, we go, right. OK, let's talk export 40 anyway. And we would say, OK, sure, we can do that. Sure. So the story behind here is like this. Nimrod did this very bad, scappy implementation of some kind of a scanner in order to look how many systems on the internet supported SSL version 2. And I did the first scan. And I found this huge amount of numbers of SSL version 2 scanners. And then I used a different scanner that just looked for SSL version 2. And it would say, no, SSL version 2 is not supported. And I debugged. And I debugged. And I debugged. It 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, want to talk export Cypher? 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. 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 2. But using a non-standard compliant SSL client. OK, so this means the server is vulnerable to drown. And this is even though you disabled SSL version 2 export Cypher, 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 RC2 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. So for non-export Cypher, we said MK Clear needs to be zero. This is not the case here. So a standard conforming client would like, right? 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 premaster secret. If we send four clear bytes along with a 16 byte premaster secret that was encrypted, it will still prepend it to the actual encrypted premaster secret. So that means K13, K14, K15 would simply fall off. 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. So now we do this in a stepping mode. 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. And then 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. OK. So that means we dub this special drown because it's a special version of this attack. The generic drown still has 2 to the 40 complexity per oracle request. And we need to have something like 1,000 oracle requests. That's pretty substantial. But this 2 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, 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 1 and 1 1⁄2 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 1 and 1⁄2 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. OK. So in summary, there's just one sentence that I can say here, ancient SSL version 2 breaks current TLS. And we can do nothing else than just disabling SSL version 2. 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. That's nothing that is really too surprising. 20 years ago, many things happened between them. We have some crypto implementation flaws from the 90s. And the OpenSSL guys were like, OK, I've never looked at SSL version 2 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. OK, so what are the mitigations for the administrators here? So disable SSL version 2 and SSL version 3 while you're at it, because SSL is insecure. Don't use the word SSL anymore. TLS is the real thing. 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. So this is the mitigation for the admin. The mitigation for the citizen, in my opinion, is vote against crypto backdoors. Thank you very much. Thank you, Sebastian. Do we have questions from the audience? OK, we have one question. I think we start with microphone 3, please. Yeah, actually, it's two questions. One is, how specific this is for RSA? I mean, would it work also for Diffie-Hellman-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-Hellman, but this is not an offline attack. It needs to be an active man in the middle. So it's your first question, and it's limited to RSA. So for example, yeah, so Diffie-Hellman doesn't work. And your second question was, excuse me? If the situation is OpenSSL or other SSL implementations has improved since hard bleed. OK, so this bug hasn't popped up in one of the audits, probably because people didn't care about SSL version 2 because it's already messed up. So people were doing a focused audit, which is what I would expect. They did a good job there. OK, thank you. Do we have questions from the internet? No. OK, 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, it links against OpenSSL. But there goes your uptime, right? 1,000 days uptime. Oh, 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, on average, 1 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 1,000, approximately. It depends on the size. It depends on the pre-master secret. But on average, 1,000 connections is what we need. OK? 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. OK. And restart your server. Your 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 we looked at, for example, the code that is in IIS, S-channel, it still supports SSL version 2, and it has the same protocols loss. So if you support SSL version 2, you're vulnerable independently of the implementation, at least how we looked at it. OK, thank you. Welcome. And I think microphone one, please. Why the name Drown? That's a good question. So Nimrod came up with the initial idea, and he has his favorite movie where this plays a role, and then we did a backronom, which I don't remember anymore. It's written in the paper. Sorry about it. I don't even know the backronom anymore. It's just a working name, and then it got viral. And of course, more information is provided on the FAH plan. So any other questions? OK, in this case, I have a question. Usually, you say, OK, which politician was it that said, OK, please, weaken the strength of 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. 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. So that's maybe one good thing about it. But in general, it's not a good idea. OK, any other questions in the meantime? I think microphone five. Is this a question? No, 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. 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. OK, 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 OpenSSL. OK, any other questions? In this case, please give an anniversary edition applause to Sebastian Schinzer. Thank you very much. Thank you.
 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 FHAR Münster.  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.  [? APPLAUSE?]  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 V2.  It's kind of old.  The attack has a name, it has a web page,  and it has even a logo.  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 like 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 V2, what is really SSL V2?  So SSL V2 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 V2 immediately died,  and the reason for that is that the creators of SSL V2,  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 V3, 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, OK, SSL V2 was  published in 1995, and it was broken in 1995.  No one's ever going to use this right now.  OK, I've got some data for you.  So this is the 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 443, 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, these old dinosaurs  all are coming back somehow to haunt us users  on the internet, right?  OK, 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 has, 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 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.  OK, 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 2.  So we need one server that supports SSL version 2.  And one very important thing is clients  don't support SSL version 2 for very long time.  So the last browser that supported SSL version 2  was Internet Explorer 6 on XP.  And even Internet Explorer 6 would always  prefer SSL version 3.  So if there's a way to negotiate SSL version 3,  it would also always use that.  So we are 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 2,  which is really strange, right?  So we break TLS using SSL.  OK, 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.  So which is pretty right.  So if everyone here gives maybe $0.50 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 POP3 client does every minute or so  to get your email, because there your password is in there.  And if you get your password, we can break all the residual.  So breaking just a single one is sufficient in most cases.  OK, I said there's a lot of puzzle pieces  that we need to do.  And I tried 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 look at what's more from my talk in 31c3.  I will show you a new protocol flaw in SSL version 2.  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 2,  which is not relevant at all, because no one is speaking  SSL version 2 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 2.  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 2,  version 3, and TLS 1.0 up to 1.2,  it will always use the same RSA key pair.  And when we take this into account,  all of a sudden, Drown becomes a practical attack  against many TLS servers.  It's practical in an academic sense.  It still means it's an expensive attack,  but we can do it.  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 2 implementation that  is out there.  Now, here we are looking into two implementation errors  in open SSL.  And 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.  OK, 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 a key.  And when I say a key, it always means a symmetric key.  So as a metric encryption, for example,  with RSA is pretty expensive.  So therefore, we just do the key exchange.  We exchange a symmetric key over RSA, which is 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 des or des  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 metric 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.  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 send this over.  And the next step, and this is a very important step  that 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.  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 the pre-master secret,  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.  So this is the holy grail that we want to break right now,  and Bleichenbach's attack achieves exactly this.  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.  OK.  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 1 or 0, so true or false,  depending on the successful decryption.  So if the decryption was successful,  and the pre-master secret looks somehow valid,  looks somehow, then it will say, OK, 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, OK, 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 1 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.  OK.  So in the original paper of Deichenbacher from 1998,  he was exploiting the fact that common TLS implementations  would like, they had 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, OK, 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 Mellet, we'll 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.  OK.  Now we exploited this very countermeasure  for Bleichenbach's attack in order  to conduct a new Bleichenbach's attack.  And it works like this.  OK.  So let's look at the SSL version 2 protocol.  It changes.  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 their 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  like 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-bit  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 0.  OK, fair enough.  OK, this is maybe not the best idea to do something like this  from a politician's viewpoint, but still, OK, it makes sense.  OK, 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 Blaischenbacher 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 Blaichenbacher oracle  with the only condition.  So we don't get any error messages from the server.  Everything is correctly implemented as any RFC,  but if we send two cipher texts, 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.  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 2.  And now you need to imagine a bunch of academics  in their ivory tower, like high fiving.  We did a new attack, a new cryptographic attack,  but it has zero relevance.  So we were missing each other, something like this.  So we need to look further.  That's not sufficient.  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 NGINs 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 3,  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.  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, 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 a specific TLS version.  It's a generic RSA decryption oracle.  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 looks 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 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, which is not a very good idea.  So it could even be that both use a different certificate  but have the same RSA key pair.  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.  When we scanned 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.  No, 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, 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,  it will fall back to plain text.  So for SMTP, bad encryption, bad cryptography  is better than plain text.  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, 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, OK,  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 1 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.  OK.  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 2 to the 40 exhaustive searches, so  encryptions or decryptions.  And we need to do this for around 1,000 oracle queries.  So that's a lot.  2 to the 50.  And so we basically 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, OK, 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.  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, OK, this is crazy.  [? Applause?]  Absolutely stunning.  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.  OK, cool.  So now we have a practical attack against many TLS servers.  And this is 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 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.  And so what many people did is they always  configured their Cypher Suites.  So they said, OK, we only use the secure Cypher Suites.  And then we disabled the ports.  So here, for example, we disabled SSL version 3  in order to prevent the Poodle attack.  But SSL version 2 was not explicitly disabled,  which meant the OpenSSL behind that,  it would enable SSL version 2.  But there was not all the export Cypher's would be forbidden.  So this Cypher Suite configuration here  would forbid export 40 bits Cypher Suites.  So therefore, Drown shouldn't work.  So how does SSL version 2 do the Cypher Suite negotiation?  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.  And then the standard compliant SSL version 2 client  would say, OK, too bad.  OK, 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, OK, bye, sorry.  It's really bad that we can't talk exports.  So if the client says afterwards, OK,  I want to 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 premaster  secret, and that also contains the Cypher Suite  that the client just selected.  It will get the SSL Cypher Suite by that char that came in.  So each Cypher Suite has one byte, or put it differently.  So there's a byte that denotes a certain Cypher 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 Suite was selected,  that is not compiled in.  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.  So basically what happens is a non-standard compliant SSL  version 2 can force that handshake.  So we say, want to talk export Cypher?  No, I don't do export Cypher.  Sorry.  OK, we go, right.  OK, let's talk export 40 anyway.  And we would say, OK, sure, we can do that.  Sure.  So the story behind here is like this.  Nimrod did this very bad, scappy implementation  of some kind of a scanner in order  to look how many systems on the internet supported SSL version  2.  And I did the first scan.  And I found this huge amount of numbers of SSL version 2  scanners.  And then I used a different scanner that just looked  for SSL version 2.  And it would say, no, SSL version 2 is not supported.  And I debugged.  And I debugged.  And I debugged.  It 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, want to talk export Cypher?  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.  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 2.  But using a non-standard compliant SSL client.  OK, so this means the server is vulnerable to drown.  And this is even though you disabled SSL version  2 export Cypher, 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 RC2 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.  So for non-export Cypher, we said MK Clear needs to be zero.  This is not the case here.  So a standard conforming client would like, right?  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 premaster secret.  If we send four clear bytes along with a 16 byte premaster  secret that was encrypted, it will still  prepend it to the actual encrypted premaster secret.  So that means K13, K14, K15 would simply fall off.  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.  So now we do this in a stepping mode.  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.  And then 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.  OK.  So that means we dub this special drown  because it's a special version of this attack.  The generic drown still has 2 to the 40 complexity  per oracle request.  And we need to have something like 1,000 oracle requests.  That's pretty substantial.  But this 2 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, 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 1 and 1 1⁄2 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 1 and 1⁄2 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.  OK.  So in summary, there's just one sentence  that I can say here, ancient SSL version 2  breaks current TLS.  And we can do nothing else than just disabling SSL version 2.  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.  That's nothing that is really too surprising.  20 years ago, many things happened between them.  We have some crypto implementation flaws from the 90s.  And the OpenSSL guys were like, OK,  I've never looked at SSL version 2 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.  OK, so what are the mitigations for the administrators here?  So disable SSL version 2 and SSL version 3  while you're at it, because SSL is insecure.  Don't use the word SSL anymore.  TLS is the real thing.  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.  So this is the mitigation for the admin.  The mitigation for the citizen, in my opinion,  is vote against crypto backdoors.  Thank you very much.  Thank you, Sebastian.  Do we have questions from the audience?  OK, we have one question.  I think we start with microphone 3, please.  Yeah, actually, it's two questions.  One is, how specific this is for RSA?  I mean, would it work also for Diffie-Hellman-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-Hellman, but this is not an offline attack.  It needs to be an active man in the middle.  So it's your first question, and it's limited to RSA.  So for example, yeah, so Diffie-Hellman doesn't work.  And your second question was, excuse me?  If the situation is OpenSSL or other SSL implementations  has improved since hard bleed.  OK, so this bug hasn't popped up in one of the audits,  probably because people didn't care about SSL version 2  because it's already messed up.  So people were doing a focused audit,  which is what I would expect.  They did a good job there.  OK, thank you.  Do we have questions from the internet?  No.  OK, 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,  it links against OpenSSL.  But there goes your uptime, right?  1,000 days uptime.  Oh, 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,  on average, 1 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 1,000, approximately.  It depends on the size.  It depends on the pre-master secret.  But on average, 1,000 connections is what we need.  OK?  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.  OK.  And restart your server.  Your 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 we looked at, for example,  the code that is in IIS, S-channel,  it still supports SSL version 2, and it has the same protocols  loss.  So if you support SSL version 2, you're  vulnerable independently of the implementation,  at least how we looked at it.  OK, thank you.  Welcome.  And I think microphone one, please.  Why the name Drown?  That's a good question.  So Nimrod came up with the initial idea,  and he has his favorite movie where this plays a role,  and then we did a backronom, which I don't remember anymore.  It's written in the paper.  Sorry about it.  I don't even know the backronom anymore.  It's just a working name, and then it got viral.  And of course, more information is provided on the FAH plan.  So any other questions?  OK, in this case, I have a question.  Usually, you say, OK, which politician was it that said,  OK, please, weaken the strength of 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.  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.  So that's maybe one good thing about it.  But in general, it's not a good idea.  OK, any other questions in the meantime?  I think microphone five.  Is this a question?  No, 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.  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.  OK, 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 OpenSSL.  OK, any other questions?  In this case, please give an anniversary edition applause  to Sebastian Schinzer.  Thank you very much.  Thank you.
33c3-7821-the_drown_attack_0_347.png 33c3-7821-the_drown_attack_348_467.png 33c3-7821-the_drown_attack_468_539.png 33c3-7821-the_drown_attack_540_659.png 33c3-7821-the_drown_attack_660_767.png 33c3-7821-the_drown_attack_768_827.png 33c3-7821-the_drown_attack_828_1019.png 33c3-7821-the_drown_attack_1020_1079.png 33c3-7821-the_drown_attack_1080_1139.png 33c3-7821-the_drown_attack_1140_1319.png 33c3-7821-the_drown_attack_1320_1403.png 33c3-7821-the_drown_attack_1404_1535.png 33c3-7821-the_drown_attack_1536_2315.png 33c3-7821-the_drown_attack_2316_2387.png 33c3-7821-the_drown_attack_2388_2711.png 33c3-7821-the_drown_attack_2712_2831.png 33c3-7821-the_drown_attack_2832_2999.png 33c3-7821-the_drown_attack_3000_3059.png 33c3-7821-the_drown_attack_3060_17807.png 33c3-7821-the_drown_attack_17808_25259.png 33c3-7821-the_drown_attack_25260_32507.png 33c3-7821-the_drown_attack_32508_37607.png 33c3-7821-the_drown_attack_37608_39431.png 33c3-7821-the_drown_attack_39432_39611.png 33c3-7821-the_drown_attack_39612_42695.png 33c3-7821-the_drown_attack_42696_57383.png 33c3-7821-the_drown_attack_57384_58463.png 33c3-7821-the_drown_attack_58464_58799.png 33c3-7821-the_drown_attack_58800_59543.png 33c3-7821-the_drown_attack_59544_66155.png 33c3-7821-the_drown_attack_66156_68063.png 33c3-7821-the_drown_attack_68064_69527.png 33c3-7821-the_drown_attack_69528_69659.png 33c3-7821-the_drown_attack_69660_70691.png 33c3-7821-the_drown_attack_70692_71627.png 33c3-7821-the_drown_attack_71628_72299.png 33c3-7821-the_drown_attack_72300_72383.png 33c3-7821-the_drown_attack_72384_74003.png 33c3-7821-the_drown_attack_74004_74399.png 33c3-7821-the_drown_attack_74400_75251.png 33c3-7821-the_drown_attack_75252_76151.png 33c3-7821-the_drown_attack_76152_78743.png 33c3-7821-the_drown_attack_78744_78851.png 33c3-7821-the_drown_attack_78852_78923.png 33c3-7821-the_drown_attack_78924_79007.png 33c3-7821-the_drown_attack_79008_80567.png 33c3-7821-the_drown_attack_80568_81923.png 33c3-7821-the_drown_attack_81924_82523.png 33c3-7821-the_drown_attack_82524_82619.png 33c3-7821-the_drown_attack_82620_82667.png 33c3-7821-the_drown_attack_82668_83383.png
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 FHAR Münster. 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. [? APPLAUSE?] 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 V2. It's kind of old. The attack has a name, it has a web page, and it has even a logo. 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 like 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 V2, what is really SSL V2? So SSL V2 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 V2 immediately died, and the reason for that is that the creators of SSL V2, 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 V3, 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, OK, SSL V2 was published in 1995, and it was broken in 1995. No one's ever going to use this right now. OK, I've got some data for you. So this is the 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 443, 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, these old dinosaurs all are coming back somehow to haunt us users on the internet, right? OK, 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 has, 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 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. OK, 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 2. So we need one server that supports SSL version 2. And one very important thing is clients don't support SSL version 2 for very long time. So the last browser that supported SSL version 2 was Internet Explorer 6 on XP. And even Internet Explorer 6 would always prefer SSL version 3. So if there's a way to negotiate SSL version 3, it would also always use that. So we are 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 2, which is really strange, right? So we break TLS using SSL. OK, 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. So which is pretty right. So if everyone here gives maybe $0.50 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 POP3 client does every minute or so to get your email, because there your password is in there. And if you get your password, we can break all the residual. So breaking just a single one is sufficient in most cases. OK, I said there's a lot of puzzle pieces that we need to do. And I tried 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 look at what's more from my talk in 31c3. I will show you a new protocol flaw in SSL version 2. 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 2, which is not relevant at all, because no one is speaking SSL version 2 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 2. 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 2, version 3, and TLS 1.0 up to 1.2, it will always use the same RSA key pair. And when we take this into account, all of a sudden, Drown becomes a practical attack against many TLS servers. It's practical in an academic sense. It still means it's an expensive attack, but we can do it. 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 2 implementation that is out there. Now, here we are looking into two implementation errors in open SSL. And 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. OK, 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 a key. And when I say a key, it always means a symmetric key. So as a metric encryption, for example, with RSA is pretty expensive. So therefore, we just do the key exchange. We exchange a symmetric key over RSA, which is 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 des or des 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 metric 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. 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 send this over. And the next step, and this is a very important step that 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. 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 the pre-master secret, 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. So this is the holy grail that we want to break right now, and Bleichenbach's attack achieves exactly this. 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. OK. 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 1 or 0, so true or false, depending on the successful decryption. So if the decryption was successful, and the pre-master secret looks somehow valid, looks somehow, then it will say, OK, 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, OK, 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 1 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. OK. So in the original paper of Deichenbacher from 1998, he was exploiting the fact that common TLS implementations would like, they had 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, OK, 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 Mellet, we'll 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. OK. Now we exploited this very countermeasure for Bleichenbach's attack in order to conduct a new Bleichenbach's attack. And it works like this. OK. So let's look at the SSL version 2 protocol. It changes. 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 their 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 like 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-bit 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 0. OK, fair enough. OK, this is maybe not the best idea to do something like this from a politician's viewpoint, but still, OK, it makes sense. OK, 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 Blaischenbacher 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 Blaichenbacher oracle with the only condition. So we don't get any error messages from the server. Everything is correctly implemented as any RFC, but if we send two cipher texts, 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. 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 2. And now you need to imagine a bunch of academics in their ivory tower, like high fiving. We did a new attack, a new cryptographic attack, but it has zero relevance. So we were missing each other, something like this. So we need to look further. That's not sufficient. 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 NGINs 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 3, 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. 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, 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 a specific TLS version. It's a generic RSA decryption oracle. 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 looks 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 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, which is not a very good idea. So it could even be that both use a different certificate but have the same RSA key pair. 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. When we scanned 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. No, 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, 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, it will fall back to plain text. So for SMTP, bad encryption, bad cryptography is better than plain text. 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, 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, OK, 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 1 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. OK. 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 2 to the 40 exhaustive searches, so encryptions or decryptions. And we need to do this for around 1,000 oracle queries. So that's a lot. 2 to the 50. And so we basically 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, OK, 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. 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, OK, this is crazy. [? Applause?] Absolutely stunning. 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. OK, cool. So now we have a practical attack against many TLS servers. And this is 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 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. And so what many people did is they always configured their Cypher Suites. So they said, OK, we only use the secure Cypher Suites. And then we disabled the ports. So here, for example, we disabled SSL version 3 in order to prevent the Poodle attack. But SSL version 2 was not explicitly disabled, which meant the OpenSSL behind that, it would enable SSL version 2. But there was not all the export Cypher's would be forbidden. So this Cypher Suite configuration here would forbid export 40 bits Cypher Suites. So therefore, Drown shouldn't work. So how does SSL version 2 do the Cypher Suite negotiation? 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. And then the standard compliant SSL version 2 client would say, OK, too bad. OK, 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, OK, bye, sorry. It's really bad that we can't talk exports. So if the client says afterwards, OK, I want to 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 premaster secret, and that also contains the Cypher Suite that the client just selected. It will get the SSL Cypher Suite by that char that came in. So each Cypher Suite has one byte, or put it differently. So there's a byte that denotes a certain Cypher 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 Suite was selected, that is not compiled in. 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. So basically what happens is a non-standard compliant SSL version 2 can force that handshake. So we say, want to talk export Cypher? No, I don't do export Cypher. Sorry. OK, we go, right. OK, let's talk export 40 anyway. And we would say, OK, sure, we can do that. Sure. So the story behind here is like this. Nimrod did this very bad, scappy implementation of some kind of a scanner in order to look how many systems on the internet supported SSL version 2. And I did the first scan. And I found this huge amount of numbers of SSL version 2 scanners. And then I used a different scanner that just looked for SSL version 2. And it would say, no, SSL version 2 is not supported. And I debugged. And I debugged. And I debugged. It 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, want to talk export Cypher? 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. 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 2. But using a non-standard compliant SSL client. OK, so this means the server is vulnerable to drown. And this is even though you disabled SSL version 2 export Cypher, 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 RC2 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. So for non-export Cypher, we said MK Clear needs to be zero. This is not the case here. So a standard conforming client would like, right? 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 premaster secret. If we send four clear bytes along with a 16 byte premaster secret that was encrypted, it will still prepend it to the actual encrypted premaster secret. So that means K13, K14, K15 would simply fall off. 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. So now we do this in a stepping mode. 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. And then 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. OK. So that means we dub this special drown because it's a special version of this attack. The generic drown still has 2 to the 40 complexity per oracle request. And we need to have something like 1,000 oracle requests. That's pretty substantial. But this 2 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, 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 1 and 1 1⁄2 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 1 and 1⁄2 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. OK. So in summary, there's just one sentence that I can say here, ancient SSL version 2 breaks current TLS. And we can do nothing else than just disabling SSL version 2. 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. That's nothing that is really too surprising. 20 years ago, many things happened between them. We have some crypto implementation flaws from the 90s. And the OpenSSL guys were like, OK, I've never looked at SSL version 2 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. OK, so what are the mitigations for the administrators here? So disable SSL version 2 and SSL version 3 while you're at it, because SSL is insecure. Don't use the word SSL anymore. TLS is the real thing. 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. So this is the mitigation for the admin. The mitigation for the citizen, in my opinion, is vote against crypto backdoors. Thank you very much. Thank you, Sebastian. Do we have questions from the audience? OK, we have one question. I think we start with microphone 3, please. Yeah, actually, it's two questions. One is, how specific this is for RSA? I mean, would it work also for Diffie-Hellman-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-Hellman, but this is not an offline attack. It needs to be an active man in the middle. So it's your first question, and it's limited to RSA. So for example, yeah, so Diffie-Hellman doesn't work. And your second question was, excuse me? If the situation is OpenSSL or other SSL implementations has improved since hard bleed. OK, so this bug hasn't popped up in one of the audits, probably because people didn't care about SSL version 2 because it's already messed up. So people were doing a focused audit, which is what I would expect. They did a good job there. OK, thank you. Do we have questions from the internet? No. OK, 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, it links against OpenSSL. But there goes your uptime, right? 1,000 days uptime. Oh, 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, on average, 1 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 1,000, approximately. It depends on the size. It depends on the pre-master secret. But on average, 1,000 connections is what we need. OK? 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. OK. And restart your server. Your 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 we looked at, for example, the code that is in IIS, S-channel, it still supports SSL version 2, and it has the same protocols loss. So if you support SSL version 2, you're vulnerable independently of the implementation, at least how we looked at it. OK, thank you. Welcome. And I think microphone one, please. Why the name Drown? That's a good question. So Nimrod came up with the initial idea, and he has his favorite movie where this plays a role, and then we did a backronom, which I don't remember anymore. It's written in the paper. Sorry about it. I don't even know the backronom anymore. It's just a working name, and then it got viral. And of course, more information is provided on the FAH plan. So any other questions? OK, in this case, I have a question. Usually, you say, OK, which politician was it that said, OK, please, weaken the strength of 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. 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. So that's maybe one good thing about it. But in general, it's not a good idea. OK, any other questions in the meantime? I think microphone five. Is this a question? No, 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. 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. OK, 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 OpenSSL. OK, any other questions? In this case, please give an anniversary edition applause to Sebastian Schinzer. Thank you very much. Thank you.
attack, we all of a sudden get a trivial attack. server first has to decrypt this ciphertext in hello. We also have a server hello. We also have it uses export 40 with MD5 as an hash algorithm. eavesdrop on the TLS connections that it sees servers that are vulnerable to drown, you will