On Tuesday, October 14, 2014, Google released details on the POODLE attack, a padding oracle attack that targets CBC-mode ciphers in SSLv3. The vulnerability allows an active MITM attacker to decrypt content transferred an SSLv3 connection. While secure connections primarily use TLS (the successor to SSL), most users were vulnerable because web browsers and servers will downgrade to SSLv3 if there are problems negotiating a TLS session.
There are several excellent articles about the attack. Adam Langley has published technical details of the attack. Matthew Green has posted a less technical blog post on the attack and Google has released a security advisory. You can test your browser using the Qualys SSL Client Test.
Who is Affected?
Websites that support SSLv3 and CBC-mode ciphers are potentially vulnerable to an active MITM attack (even if the site supports TLS). We have been performing scans of the Alexa Top 1 Million Domains and the full public IPv4 address space to measure (1) the highest TLS version that each site supports and (2) whether sites support SSLv3 at all. Servers that support SSLv3 (along with TLS) are vulnerable to the attack. Sites that only support SSLv3 (and do not support TLS) are not only vulnerable, but are holding back web browsers from removing support for the compromised protocol.
Alexa Top 1 Million Domains
When POODLE was disclosed, nearly all (96.9%) of the HTTPS Top Million websites supported SSLv3. In order to check for SSLv3 and TLS support, we performed DNS lookups for each of the domains, and then connected to each IP address and recorded the highest version of TLS supported. We then performed a secondary SSLv3 handshake to determine whether each site supported SSLv3. The numbers represent which sites support SSLv3, not which sites support SSLv3 and also prefer a CBC-mode cipher suite.
| Highest TLS Version |
** Sites** |
** Percentage** |
| HTTP Only |
392,956 |
(41.2% of All Alexa) |
| SSLv3 |
1,186 |
(0.12% of Alexa, 0.02% of HTTPS Alexa) |
| TLS 1.0 |
229,001 |
(24.0% of Alexa, 40.9% of HTTPS Alexa) |
| TLS 1.1 |
3,820 |
(0.4% of Alexa, 0.7% of HTTPS Alexa) |
| TLS 1.2 |
326,479 |
(34.2% of Alexa, 58.3% of HTTPS Alexa) |
| SSLv3 Support |
Sites |
** Percentage** |
| SSLv3 Supported |
542,902 |
(96.9% of HTTPS Alexa) |
| No SSLv3 Support |
17,584 |
(3.1% of HTTPS Alexa) |
Browser Trusted Certificates (Public IPv4 Address Space)
A slightly higher percentage (98.2%) of all sites with browser trusted certificates support SSLv3. In order to measure the deployment of SSL for the full IPv4 address space, we performed a port scan on port 443 for the entire public IPv4 address space using the ZMap Internet Scanner. We attempted to perform both a TLS handshake and SSLv3 handshake to determine both the highest version of TLS that each host supported and whether SSLv3 was supported at all. We then performed certificate validation using the golang TLS library and Mozilla NSS’s root certificate store. We have also posted our raw data for public IPv4 addresses which only support SSLv3.
| Highest TLS Version |
Sites |
| SSLv3 |
0.8% |
| TLS 1.0 |
35.4% |
| TLS 1.1 |
0.4% |
| TLS 1.2 |
63.4% |
| SSLv3 Support |
Sites |
| SSLv3 Supported |
98.1% |
| No SSLv3 Support |
1.19% |
All Certificates (Public IPv4 Address Space)
Here, we show the breakdown of support for all hosts on the public IPv4 address space, which was collected using the same methodology as Browser Trusted Certificates, but without any certificate validation.
| Highest TLS Version |
Sites |
| SSLv3 |
2.8% |
| TLS 1.0 |
59.7% |
| TLS 1.1 |
0.6% |
| TLS 1.2 |
36.9% |
| SSLv3 Support |
Sites |
| SSLv3 Supported |
96.9% |
| No SSLv3 Support |
3.1% |
