# SSLv2 doesn't block disabled ciphers (CVE-2015-3197)

OpenSSL still completed SSLv2 handshakes with disabled ciphers unless SSL_OP_NO_SSLv2 was set, leaving servers DROWN-vulnerable despite cipher-level disabling.

- Payout: hidden
- Severity: low
- Program: Internet Bug Bounty
- Found by: nimia
- Disclosed: 2016-09-21
- CVE: CVE-2015-3197
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/166634
- Library page: https://bugbountylibrary.com/r/h1%3A166634
- Tags: area:oss domain:oss impact:data-leak kind:bounty platform:hackerone sev:low technique:chained vuln:crypto vuln:misconfiguration

**Target:** TLS/SSL library SSLv2 handshake negotiation
**Root cause:** Disabling individual SSLv2 ciphers did not prevent SSLv2 handshakes; only SSL_OP_NO_SSLv2 fully disabled the protocol, so servers configured by cipher removal still spoke SSLv2.
**Steps:**
1. Configure server with all SSLv2 ciphers disabled but without SSL_OP_NO_SSLv2.
2. Client initiates an SSLv2 handshake.
3. Server negotiates an SSLv2 cipher that was supposedly disabled and completes the handshake.
**How found:** DROWN research into SSLv2 exposure revealed servers still answering SSLv2 despite cipher-level disabling, prompting inspection of OpenSSL's protocol-vs-cipher disable logic.
**Exploitation:** DROWN attackers use SSLv2 handshake support (RSA export cipher oracle) to decrypt captured TLS traffic; this flaw meant servers believing SSLv2 disabled remained exploitable.
**Escalation:** Chained into the DROWN cross-protocol attack to decrypt TLS sessions.
**Insight:** When auditing protocol disablement, test whether removing ciphers actually blocks the protocol version; a separate protocol-level flag may be the only real kill switch.