DROWN vs POODLE

Lately, the DROWN SSL vulnerability has been in the news. It brings to mind 2014's POODLE vulnerability, which has some similarities.

Both are issues with obsolete SSL versions. When they connect, many SSL/TLS clients will try the highest version they support, say TLS 1.2. If the handshake (the connection establishment process) fails, the client tries lower versions in succession until the connection succeeds.

This negotiation process can be dangerous, as shown by POODLE. Older SSL/TLS versions are not as secure as more recent versions - vulnerabilities have been discovered and fixed in later versions. If attackers can force the use of these more insecure versions, their job will be much easier.

POODLE was a man-in-the-middle attack. An attacker could interfere with a client's handshake with the server so that it failed, resulting in the client downgrading the version. If they could be forced down to using SSL 3.0, then the attacker can exploit the knowledge that there are no secure cipher suites in SSL 3.0. The solution is to disable use of SSL 3.0 in servers.

DROWN is different - it doesn't directly interfere with the client's connection. Instead, DROWN is an attack on an even older protocol version, SSL 2.0, which is still supported by many servers. It works on any server that uses the same private keys for SSL 2.0 and higher versions of SSL/TLS (likely). The attacker connects using SSL 2.0, and is able to eventually determine the secret session keys of a currently connected user session (which might be using TLS 1.2). This enables the attacker to decrypt the user's current session data. Here the solution is to disable support for SSL 2.0.

Both POODLE and DROWN demonstrate the importance of disabling older, more insecure versions of SSL on servers.