What is DROWN and how does it work?

To understand the attack, one must recall Bleichenbacher's attack from the late 20th century. In that attack, the attacker uses the target server as an oracle. When using RSA-based key exchange, the client is supposed to send a secret value (the "pre-master secret") encrypted with the server's public key, using PKCS#1 v1.5 padding (called "type 2"). Bleichenbacher's attack relied on sending carefully crafted values in lieu of a properly encrypted message, and observe the server's reaction. The server might respond (most of the time) with an error saying "I processed that but it did not yield a proper PKCS#1 v1.5 type 2 padding"; but sometimes, the decryption seems to work and the server proceeds with whatever it obtained. The attacker sees that difference in behaviour, and thus gains a tiny bit on information on the private key. After a million connections or so, the attacker knows enough to perform an arbitrary decryption and thus break a previously recorded session.

This attack is of the same kind, but with a new technique that relies on the specificities of SSL 2.0. SSL 2.0 is an old protocol version that has several serious flaws and should not be used. It has been deprecated for more than 15 years. It has been even formally prohibited in 2011. Nevertheless, some people still support SSL 2.0. Even worse, they support it with so-called "export" cipher suites where encryption strength is down to about 40 bits.

So the attack works a bit like this:

1. The attacker observes an encrypted SSL/TLS session (a modern, robust one, say TLS 1.2) that uses RSA key exchange, and he would like to decrypt it. Not all SSL/TLS sessions are amenable to the attack as described; there is a probability of about 1/1000 that the attack works. So the attacker will need to gather about a thousand encrypted sessions, and will ultimately break through one of them. The authors argue that in a setup which looks like the ones for CRIME and BEAST (hostile Javascript that triggers invisible connections in the background), this collection can be automated.

2. The server carelessly uses the same RSA private key for a SSL 2.0 system (maybe the same server, maybe another software system that may implement another protocol, e.g. a mail server). The attacker has the possibility to try to talk to that other system.

3. The attacker begins a SSL 2.0 handshake with that system, using as ClientMasterKey message a value derived from the one that the attacker wants to decrypt. He also asks for using a 40-bit export cipher suite.

4. The attacker observes the server's response, and brute-forces the 40-bit value that the server came up with when it decrypted the value sent by the attacker. At that point, the attacker knows part of the result of the processing of his crafted value by the server with its private key. This indirectly yields a bit of information on the encrypted message that the attacker is really interested in.

5. The attacker needs to do steps 3 and 4 about a few thousand times, in order to recover the encrypted pre-master secret from the target session.

For the mathematical details, read the article.

Conditions for application:

• The connection must use RSA key exchange. The attack, as described, cannot do much against a connection that uses DHE or ECDHE key exchange (which are recommended anyway for forward secrecy).

• The same private key must be used in a system that implements SSL 2.0, accessible to the attacker, and that furthermore accepts to negotiate an "export" cipher suite.
  Note: If OpenSSL is used and not patched for CVE-2015-3197, even if "export" cipher suites are disabled, a malicious client can still negotiate and complete a handshake with those disabled cipher suites.

• The attacker must be able to make a few thousands or so connections to that SSL 2.0 system, and then run a 40-bit brute force for each; the total computing cost is about 2⁵⁰ operations.

It must be well understood that the 2⁵⁰ effort is for each connection that the attacker tries to decrypt. If he wants to, say, read credit card numbers from connections he observes, he will need to make a non-negligible amount of work for each credit card number. While the attack is very serious, it is not really practical in that CCN-grabbing setup.

---

The solution: don't use SSL 2.0. Dammit. You should have stopped using SSL 2.0 in the previous millenium. When we said "don't use it, it is weak", we really meant it. It is high time to wake up and do your job.

Supporting weak ("export") cipher suites was not a smart move either. Guess what ? Weak crypto is weak.

Deactivating SSL 2.0 is the only right way to fix the issue. While you are at it, deactivate SSL 3.0 as well.

(And that fashion of using all-uppercase acronyms for attacks is really ridiculous.)

The answer by Thomas is wonderful. There is just one thing that seems understated: e-mail servers are broken security-wise... by default and by design.

• default: just look at the default postfix configuration for instance (hint: SSLv2 and 40-56bit ciphers are still a thing, and "no encryption" too).

• by design: have you ever heard of the StartSSL wonder? Well, it is the only non-deprecated way to achieve encryption with SMTP (the "e-mail" protocol). What's wonderful with StartSSL is that it is usually strong when nobody is listening, but can be easily made to default to clear text if someone wants to read... or SSLv2 if someone wants to read HTTPS instead...

  ¯\_(ツ)_/¯

See there for an example of both the state of mind of people in the SMTP realm and a few glimpses of configuration. Please note that there is no such thing as a single flag to disable SSLv2 in postfix (well, there is one, but don't be surprised if the server still accepts and responds to SSLv2 afterwards).

How is that even related to the question?

You can harden your web server as much as you want, if you have a SMTP server running on a valid certificate, chances are high that you are vulnerable to that same "DROWN" attack. Even worse, your web server will be too... well usually: you'd be surprised by how many SMTP servers share their certificates with the HTTP server. You'd also be surprise by the validity domain of some "stand-alone" SMTP certificates.

Solutions?

1. Configure your SMTP server properly (and check the configuration with external tools such as sslyze)
2. Or disable SMTP altogether.
3. Or use a self-signed/subdomain-specific certificate with SMTP.