The vulnerability here is tricky to exploit but actually simple to describe.
There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack.
But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS and SSLv2, the anti- padding- oracle trick is that the server detects bad messages and then generates a fake message to continue running the protocol with, instead of aborting (which would reveal to the attacker that the message was corrupt, thus enabling the padding oracle). But when SSLv2 does that, the attacker can detect that it did, because the cipher key lengths in SSLv2 are so short that they can be brute forced. The attacker knows when the SSLv2 server replaced its message with a fake one, and thus has a working padding oracle.
The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them.
It's a great, great paper. The Bardou "trimmer" stuff was news to me too! :mind-blown-emoji:
The top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.
To me, the real problem here is RSA. Virtually every system on the Internet that does RSA uses PKCS1v15 padding (DNSSEC, which is only now being rolled out after nearly two decades of standards work, uses PKCS1v15 padding!). Moreover, RSA directly exposes an encryption primitive, unlike DH+signature forward-secure protocols, and RSA ciphertexts are surprisingly malleable.
To me, the real takeaway: RSA is obsolete. Stop using it.
An "oracle" is simply an circumstance in which an adversary can coerce you to use your secret key to do a useful computation, some result of which is revealed.
Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error."
Think of error oracles this way: imagine a situation in which an adversary can hand you a ciphertext which, when decrypted, will trigger an error (in a padding oracle, that error is "the padding is wrong"). Now imagine that the error, revealed to the adversary, allows them to infer one bit of the plaintext. Not very useful by itself, but, as a final step, imagine that the attacker can permute the same ciphertext, generating (or not generating) an error and allowing them to reveal a different bit of the plaintext.
As long as they can keep doing that, they'll eventually recover the whole plaintext.
This is a great explanation and I appreciate you providing it.
I think the point GP was making was that he got literally 4 words into the "simple to explain" explanation before realizing this explanation is going to be like tons of other things he reads here and elsewhere that require so much prior and specialized knowledge as to be nearly impossible for someone lacking a high level of experience in the area to understand.
I often feel this way when security topics come up on HN. I've been writing code a long time and I think I'm of moderate intelligence and I often have no idea what anyone is talking about. I try not to lose sleep over it because I understand that security can be really, really complicated (even if the issue is "easy to explain") and so I'm just not going to get it.
Right. Well, you're not going to get the exploit from a simple description of the attack. DROWN is built on some well-known attacks on RSA, most notably Bleichenbacher's 1998 padding oracle attack, but the specifics of how to manipulate an RSA ciphertext to make TLS records intelligible to SSLv2 are hairy even if you've implemented BB98 before --- I'm going to call this "stunt Bleichenbachering".
So it's not very important that you understand exactly how to go from "errors/exceptions generated by the target" to "recovery of plaintext". Even if you understand the specifics of those kinds of attacks, they're even more complicated (and fun) here.
The interesting nut of the attack is: there's a well-known error oracle in both TLS and SSLv2, but it's long since been mitigated in both protocols. However, details of the crappy crypto in SSLv2 conspire to make the mitigation for padding oracles in SSLv2 ineffective, and you can use the SSLv2 oracle to attack TLS ciphertexts if TLS and SSLv2 ever share keys.
No, that's just tradition. Error oracles are a crypto thing; the errors don't even need to be exposed to users for them to be a problem (for instance, the Lucky13 TLS attack uses timing to discern exceptions, not actual error messages).
Had to deal with a program recently that gave "corrupted MAC" error on the server. All searching etc hinted at it being a network issue. Only after having fiddled with the network for ages and getting nowhere did i set up a loopback test and found the same error.
Turns out the program i was dealing with was using an old lib.
Imagine it like you're looking through a keyhole at a computer monitor.
It's setup so that you can only see the very last letter in what you think is a really long sentence someone has typed into a text editor.
With your bluetooth keyboard you move to the beginning of the line and repeatedly hit the spacebar, taking note each time what the new letter is that you can see through the keyhole.
I ran across a related issue working on a project that I think helped me understand the broader issue better. I'll relate it here and see if it helps.
We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched.
Phone numbers were restricted information for some users, and we didn't display them in the search results. But you could search by those fields, if you already knew the value.
It turned out we left 'partial matching' available in the phone number field.
If you knew the name of a particular person, you could do the following:
Enter their name to confirm a single match shows up.
Then enter the same search, but put a single digit in the phone field, say "0". If no result came back, you knew that their phone number didn't start with that digit. So you try the next, 1, 2, 3... when you hit, say 5, you get a result. Now you know their phone number starts with a 5.
So you start on the next digit. 50-, 51-, 52-... and you get the next digit. Eventually you can reveal their entire phone number, and it was fast enough to do manually.
It wasn't super critical for the internal system, so we changed the phone numbers to exact match only and that was fine. but let's continue.
Let's say we had a REALLY slow system, and it checked each digit one at a time, taking one second per digit, and sent back a failure when it hit a non matching digit. We aren't leaking information DIRECTLY, you get no records back for partial matches. But we ARE leaking information indirectly. The attack now works roughly like this:
Do the same verification search to get a record.
Now do the same digit by digit search, start with 0. Carefully time the delay when you submit the question, and when the error shows up. If it's almost instant, you know the first digit failed. If it takes about a second to give you an error, you know the first digit worked.
You then continue to the second digit. One second fails, two seconds verifies.
Using only the timing you can determine each digit, and reveal the entire number. This is not the main information channel, the timings are what they call a side channel. The service that gives you this information by responding with an error and varying the time is an 'oracle' because it answers your questions.
This seems clear at a one-second time scale and obvious when it's explained, but it turns out that even over public networks with enough tries you can determine very small time differences, on the millisecond or less scale.
It turns out there are a lot of variations on this, some of them are very complex, and secure systems need to work very hard to run in the same amount of time ("constant time") for any query to avoid leaking information this way. The timing exploit described above is a very simplified form of the root of the described vulnerability.
This situation helped me understand 'timing attacks' and 'oracles' in a more mundane coding context, and hopefully it will help others.
The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made good progress shifting towards DH/ECDH ciphersuites -- and TLS v1.3 will eliminate RSA entirely -- we have essentially no deployment of DSA/ECDSA certificates. It's all RSA. So "getting rid of RSA" sounds good, but won't happen in TLS/SSL anytime soon.
Moreover, if we can't get rid of export ciphersuites after twenty years, what is the probability that we'll manage to get rid of RSA in just a few? I'm not that optimistic.
There would be very little problem with RSA in TLS if people had moved to modern schemes like OAEP and RSA-PSS. The problem is that we didn't, and we're stuck with obsolete crap. Moving away from obsolete crap isn't the solution, it's the definition of the problem.
Moving away from obsolete crap isn't the solution, it's the definition of the problem.
One could argue that the CA/Browser forum has achieved some success with moving away from SHA-1. As a spectator, I don't understand why this process is not repeated for similar obsolete primitives or standards.
I read an blog post by a guy with a long experience with this. What happens is large players demand that there be a 'reasonable' deadline for compliance. And then half the companies involved sit on their hands for two and a half years and then demand an extension. And then another and next thing you know you're still using RSA fifteen years after people knew they needed to stop using it.
Only solution I can think of is to create some sort of license where once the sunset deadline is established, the license to use it expires hard on the deadline.
Thanks that would be the one. I get this feeling that encryption protocols and standards often end up and all sorts of dank corners of the web infrastructure and finding and updating all of these is really messy task. And I suspect service providers and their customers haven't been really good at keeping track of everything.
Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?
The browsers say what they accept, the server says what it provides and something in the intersecting set will be used.
If (as a random example that didn't annoy me at all for 2 years) a website also needs to support SmartTV devices which only accept obsolete certificates then your server has to either break them or not.
Another browser beside Chrome, Firefox and IE? OK, so Symantec announces that they will only use Opera. Even then, they have to deal with their customers, website operators who need a certificate trusted by the big 3 browsers, leaving. In fact, now that Let's Encrypt certificates are free, it seems like this is the Symantec CA's worst nightmare.
Why argue about which battle to fight, and try to do both? Get widespread support for ECDSA; get RSA implementations up to date with modern padding schemes. We don't need to pick and choose which modern crypto to use; use modern crypto everywhere.
Obviously upgrading old clients is hard, but that's going to be a problem regardless. So in new standards that need RSA (e.g. something where the private key needs to be able to encrypt and sign), push for OEAP. If they don't need RSA, push for modern curves.
Because even if you use OAEP, RSA is more error-prone --- particularly at a design level --- than curve cryptosystems and, for most applications, doesn't allow you to express anything you couldn't express better with curves.
Public key encryption transforms are one of the biggest foot-guns in cryptography. OAEP is at least not prima facie broken, but using it still exposes you to the the design risks of building with public key encryption.
(There are attacks against OAEP, but they're less common and not intrinsic to the design the way PKCS1v15's are).
Even if RSA does go away, and it will, public-key encryption primitives won't. The post-quantum craze is mostly made up of encryption and signature primitives, so we have that to look forward to. Even the lattice-based key agreement we have is basically fancy KEM, which leads to things like [1].
My impression is that RSA never really got the "djb treatment". The people designing OAEP and friends were mostly theorists concerned with security reductions, not implementation issues. I think an idiot-proof RSA scheme could be devised, but it is now way too late for that.
The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?).
Neither Curve25519 nor Curve448 - which are said to be safe - are usable with X.509 and TLS, yet. Still waiting for that RFC to get past the draft status.
> The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe.
I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually.
P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.
- Use RSA until 25519/448 land in TLS
- Switch to ECDSA in the interim
Personally, I would switch even though ECDSA isn't great.
The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible.
You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy.
Even Bernstein doesn't argue that the NIST curve seeds are actually backdoors. Schneier isn't a curve researcher; in fact, he's more like an anti-curve pundit. I'm not sure his opinion is all that powerful.
Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.
I would recommend against using them if your adversary is the NSA and your threat model comes wrapped in tin foil (and if I didn't, I'd get ignored anyway).
If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone.
If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).
drdaeman says that Curve25519 isn't usable with X.509 and TLS. Your reply is "Use Curve25519". What are you saying? That drdaeman is wrong, and Curve25519 can be used with TLS? Or are you saying, "don't use TLS"? Or... what?
X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support.
X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while.
On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another.
High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist?
Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.)
Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity.
Long live TLS. May it forever waste my time and energy.
"The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them."
That is a lesson worth remembering: something acquired in one context might become valuable in an attack in another context. I've seen this concept show up repeatedly hacking and security analysis. Clever how this attack applied it.
I've occasionally wondered if that could be turned into some mental framework or heuristics for generically applying it to various security analyses. Some systematic way, maybe semi-automated, of saying we've collected all these pieces of information for protocols, configs, etc. Now what does that automatically infer in terms of attacks or even connections that might lead to them?
Not sure that it's feasible in general case. I used it in prototype security scanners before the commercial ones showed up. Might be something to be had researching the concept further. (shrugs)
I'm with you on this one. This 'RSA is evil' conclusion is like taking a look at [1]---or the gazillion Schnorr-style signature scheme nonce leaks published over the years---and concluding that elliptic curves are evil.
I concede that "RSA is obsolete" is somewhat hyperbolic, given OAEP and PSS, but RSA is dangerous, more dangerous than modern curve crypto. Developers overestimate their ability to mitigate dangers.
I think developers of elliptic curve crypto overestimate their ability too. Avoiding side channels in RSA is easier than avoiding them in ECC - fewer moving parts.
Developers that are likely to expose exploitable side channels in curve software are just as likely to expose them in RSA software. But developers that use curve software are going to avoid a bunch of vulnerabilities that are specific to RSA. They should use curves, and avoid RSA.
But I don't know why I'm letting you off the hook on this. Can you be as specific as you can about the additional moving parts you're referring to? Is your comment about the difficulty of getting constant time key agreement or verification specific to legacy Weierstrass curves? And are you concerned about timing leaks in something other than scalar multiplication? If so, what are those other things?
When you say there are "more moving parts", are you referring to the fact that there's both a modular reduction and a scalar multiplication that need to be protected?
The amount I tend to learn after you get invested in a thread and start busting out things I've never heard of is honestly my counterpoint to arguing on the Internet being unproductive. That it is Percival you are fencing makes me look forward to the rest of this thread, because EC vs RSA is an interesting dialogue and you both have a lot to say on it. It might look like arguing to both of you, but scraps of useful information do fling off and I appreciate your arguing.
This thread and others like it make me think we need a security (and general) debate series.
Colin and 'pbsd are much smarter than me, and learning stuff is actually why I'm so happy to pick fights with them.
I was a blog-arguer before HN, and a Usenet person before blogs, and a BBS person before that, and most of what I've learned in my whole career is traceable somehow to Internet arguments.
I come back to my debate point. I think tech is in a state now where we definitely have personal policy positions but as engineers, we are reluctant to frame what we do that way. This is in contrast to politics where most issues are acceptably on a spectrum, because that is more of a "soft" field. I suspect "RSA is obsolete" is one of those things where you've carved out a position on one end, much like Schneier carved out his position on one end of curves as discussed upthread. I'm not calling you wrong, mind, as that comparison might imply: just a surprising opinion and you've certainly earned it, and I like hearing about it, and I think of you as one colorful end of a spectrum on this and a few other points. And throughout my life the extreme opinions have often panned out (i.e. Snowden), so I don't dismiss them much any more.
(Though I wonder if you can make a pedantic argument, that if the domain of your one-way function is suitably restricted (eg to passwords humans actually come up with) they do become bijective.)
> The top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.
The US government never misses a propaganda opportunity: "uncrackable crypto and impenetrable devices are evil". But technical people so easily miss the marketing value of sound bites.
This is a clear-cut case in which yet another major Internet security vulnerability is significantly caused by US government policy. Why shouldn't we run with this as a way to explain to the public why regulation of crypto is bad?
Another valuable takeaway is that forward secrecy is well worth having. In this case, any previously collected trove of sessions that used DHE/ECDHE is not de-cryptable by using DROWN.
Having had to briefly use an old PalmOS phone when my previous phone died, I can say that very few HTTPS sites still support SSLv2. However, most imap/pop servers seem to still support it.
This. I've typed in one of my domain names and found out my Postfix had SSLv2 for some odd reason. No idea why, I always assumed the defaults had SSLv2 properly disabled. Wrote explicit `smtpd_tls_protocols = TLSv1, TLSv1.1, TLSv1.2, !SSLv2, !SSLv3`, reloaded the daemon, ran ` openssl s_client -connect localhost:25 -starttls smtp -ssl2`, saw the negotiation failure, hope I'm good now.
So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right?
Two very important things come form that:
Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2.
> Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
I kept v2 running because we couldn't bring ourselves to prevent connections from clients of our clients, it's not our place to tell them what to do, especially if it only harms them and no one else. This time it harms everyone, including high-privilege users, so it's a lot easier to justify.
> To me, the real takeaway: RSA is obsolete. Stop using it.
RSA also has the nice property of being deterministic.
ECDSA may not be, depending on how you implement it. EDDSA is.
This matters a great deal in a world where it's important to assume your hardware may have some adversarial properties. It's much easier for your ECDSA device to purposefully leak your private key than it is for RSA (both because there's an explicit covert channel available, and also because of how much smaller elliptic key-pairs are in practice).
Also, as we prepare for a post-quantum crypto world, this might be a bad time for shorter keylengths.
There are lots of great reasons to use curves, but I think describing RSA as obsolete is a little premature.
I don't think reasonable key lengths are going to make much of a difference if quantum computing becomes a practical threat. All the RSA cryptosystems and all the ECC cryptosystems will fall.
Meanwhile: the literature suggests that RSA and classical DH keys are threatened much more by conventional computing advances than curve keys; curve keys resist index calculus attacks.
To me, as a SW engineer, the mitigation against the padding oracle attack in SSLv2 (pretend its correct and generate random PMS) seems like a very bad hack. Is there some better, more modern way to protect against bad input that eliminates this entire class of problems, similarly as we use encrypt-then-HMAC or GCM for encryption?
There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack.
But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS and SSLv2, the anti- padding- oracle trick is that the server detects bad messages and then generates a fake message to continue running the protocol with, instead of aborting (which would reveal to the attacker that the message was corrupt, thus enabling the padding oracle). But when SSLv2 does that, the attacker can detect that it did, because the cipher key lengths in SSLv2 are so short that they can be brute forced. The attacker knows when the SSLv2 server replaced its message with a fake one, and thus has a working padding oracle.
The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them.
It's a great, great paper. The Bardou "trimmer" stuff was news to me too! :mind-blown-emoji:
The top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.
To me, the real problem here is RSA. Virtually every system on the Internet that does RSA uses PKCS1v15 padding (DNSSEC, which is only now being rolled out after nearly two decades of standards work, uses PKCS1v15 padding!). Moreover, RSA directly exposes an encryption primitive, unlike DH+signature forward-secure protocols, and RSA ciphertexts are surprisingly malleable.
To me, the real takeaway: RSA is obsolete. Stop using it.
† We walk you through this vulnerability in our challenges here: http://cryptopals.com/sets/6/ --- start with #46