The DROWN paper landed at the start of the month — Drowning Down with Obsolete and Weakened eNcryption (drownattack.com paper, Aviram et al, March 2016). It is in a direct line of descent from FREAK and Logjam: another cryptographic ghost from the export-control era, dormant in the protocol surface, attackable in 2016.
The attack works as follows. SSLv2, the protocol from 1995 that should have been retired in 1996 and was effectively superseded by SSLv3 (now also obsolete), retains support on a non-trivial fraction of internet-facing TLS hosts. Many of those hosts are configured to support both SSLv2 and modern TLS — sometimes deliberately for legacy compatibility, sometimes accidentally because of default configurations on older OpenSSL versions or particular product builds. Where the SSLv2 endpoint and a TLS endpoint share an RSA key — which is common, because they are often the same server with different listening ciphersuites — an attacker who can observe a TLS-1.x session against the modern endpoint can use the SSLv2 endpoint as a Bleichenbacher-style padding oracle to recover the RSA-encrypted premaster secret of the modern TLS session. The result is decryption of TLS traffic that the modern endpoint, in isolation, would have protected adequately.
The attack exploits a flaw in SSLv2's handling of export-grade ciphersuites. SSLv2 specifies a 40-bit symmetric encryption mode for export use, and the handshake produces an RSA-encrypted master_key whose first eleven bytes are zero except for known padding. This structure makes SSLv2 a particularly cheap padding oracle against the shared RSA key. The number of oracle queries required to break a single TLS session is in the low hundreds of thousands; the cost is computable in tens of thousands of dollars of cloud compute. Two variants are described in the paper, with the General variant working against any host running an SSLv2 implementation that respects the specification, and the Special variant working specifically against OpenSSL versions affected by an additional pre-existing vulnerability that makes the attack two thousand times faster. CVE-2016-0703 and CVE-2016-0800 are the relevant assignments (cve.mitre.org/CVE-2016-0800).
The internet-wide measurement in the paper is the operational headline. Approximately 33% of all HTTPS servers are vulnerable to the General variant. The actual exploitable population — servers where the SSLv2 endpoint and a modern TLS endpoint share keys — is around 22% of HTTPS servers in the Alexa top million. That is a remarkable number for a flaw in a protocol that has been formally deprecated for two decades. The reason is the configuration default question that bedevils every retirement-of-cryptographic-functionality conversation: the cost of removing SSLv2 support is small but non-zero, the cost of the resulting customer support tickets from people running ancient browsers is salient, and the cost of leaving SSLv2 enabled is invisible until somebody publishes a paper.
Operationally, the action this week. Test every customer TLS endpoint for SSLv2 support; the SSL Labs scanner (ssllabs.com/ssltest) flags this directly. Disable SSLv2 on every server we administer — the OpenSSL configuration to remove it has been documented for years; the SSL_OP_NO_SSLv2 flag and the cipher-list directive !SSLv2 do the work. Verify the change has propagated through load balancers, reverse proxies, and any TLS-terminating intermediary. Check that no server listening on port 25 (mail) supports SSLv2 — the paper points at SMTP STARTTLS deployments as a particularly vulnerable population. Update OpenSSL to the patched versions released alongside the disclosure (1.0.2g and 1.0.1s).
For the vCISO clients, the audit posture matters. Browne Jacobson's external surface is on Cisco load balancers; the Cisco SSLv2 status was a five-minute check, clean. Towry's trading-platform refresh — now in deployment — is on a current configuration with no SSLv2 anywhere; clean. Northcott's perimeter is on Palo Alto, with the SSLv2 ciphersuites disabled at the platform level by default; clean. The mid-size UK manufacturer added in March 2015 has more legacy estate, including a couple of older Apache 2.2 deployments behind the corporate web filter, and we found two SSLv2-supporting hosts on the internal-only network. Those are being remediated this week.
The structural piece — and this is becoming a recurring theme across FREAK, Logjam, POODLE, DROWN — is that the deprecation of obsolete cryptographic functionality is, structurally, dependent on the deployment population removing it from production, and the deployment population's incentive to do so is weak until somebody publishes the attack. The TLS 1.3 standardisation work currently ongoing at the IETF (draft-ietf-tls-tls13) explicitly removes a great deal of legacy ciphersuite support, and the IETF discussion has, post-DROWN, become noticeably more sympathetic to aggressive removal. Whether that translates into deployment is the question for 2017 and 2018.
The export-control history of TLS continues to be the long essay I want to write properly. FREAK, Logjam, and DROWN are three points in a line. The line continues. There is more to come.