Tech Solvency - The Story So Far

POODLE (CVE-2014-3566)

or, "How to disable SSLv3 everywhere if you can, or mitigate POODLE if you can't"

< Return to The Story So Far (list of notable security events)

If you see something missing, please let me know!


POODLE is a padding oracle attack that affects all SSLv3 clients and servers (because it is a protocol issue, not an implementation issue). It is not like Heartbleed in that it requires MitM to exploit. It is similar to BEAST. A new-ish extension to SSL (TLS_FALLBACK_SCSV) fixes it long term. Google/Chrome is already deploying it, and it is also in the latest OpenSSL. But do not let that deter you from moving now to start eliminating SSLv3.

If you can get away with disabling SSLv3 server-side, I'd do it. For clients you don't control, IE6 on XP is the biggest client impact, but don't forget non-HTTP services (SSL VPN, SMTP STARTTLS, etc.) For clients you do control, it's time to disable SSLv3. Expect long-tail echoes of embedded devices, APIs, and similar fallout. PayPal and downstream shopping carts are likely to be tricky.

Many products that can disable SSLv3 may not have all of the newer protocols enabled. If TLS 1.0 is the only option, take it. If TLS 1.1 and 1.2 are available, use them and disable TLS 1.0 if you can. Note that this may affect more clients.

In a broad sense, more SSLv3 discoveries are likely, and may be worse. Press now to turn down SSLv3 wherever you can. Where you can't, consider proxying, tunneling, or isolating subnets. If only access to specific sites is needed, filter to allow SSLv3 to only those sites, and provide an alternate client/browser for all other work.

I am not a PCI/HIPAA expert, but I suspect that many auditors will now see SSLv3 as being "an insecure protocol" - on the same blacklist as SSLv2. At a minimum, consider creating a documented sunset/containment/isolation plan so that remediation is demonstrably underway. Remote management (HP ILO, IPMI/BMC) on in-scope systems would also be a juicy target.

Note that a couple of experts have asserted that POODLE can only be practically exploited using JavaScript in a web browser, so prioritize your mitigation accordingly.


If you see something missing, please let me know!



Independent speculation then ended up being right:
From Thomas Pornin, one of the highest-ranked guys on the security Stack Exchange:
"@RŠ¾ryMcCune I don't have a twitter account. If you want, you may answer in my name: "my guess is a BEAST-like attack that abuses the ignored bytes in SSL 3.0 padding (1/256 chance of unnoticed alteration, modifies IV for next record).
Workaround: deactivate SSL 3.0 support (in browsers or servers or both)."

Official announcement and writeup from discoverers:
- Also see their list of all SSLv3-only IPs here:



Thomas Pornin:
Adam Langley (Google) - excellent:
- and then, Google announced that they are disabling SSLv3 fallback:!topic/security-dev/Vnhy9aKM_l4
Daniel Stenberg (Mozilla/cUrl):
Ivan Ristic (Qualys SSL Labs):
Juliano Rizzo @julianor: POODLE less requirements than BEAST but slower than CRIME
Daniel Franke (technical historic analysis):

Cisco: and

Industry commentary

John Bonneau on inconsistent browser-vendor response (motivating the wrong consumer choices):

Attack Surface survey: aka This also shows Alexa sites still supporting SSLv3, and other useful data. Also includes links to client and server mitigations.

ICSI Berkeley stats:

Detection and testing


SANS ISC (client):
Qualys SSL Labs (client):
Qualys SSL Labs (server): Qualys SSL Labs (server - beta / sneak preview of new tests, stay ahead of the curve):
Poodlebleed (server): (server):


Bash nmap one-liner (server):

nmap --script ssl-enum-ciphers -p 443 | grep -A 1 SSLv3: \
    | if grep -q "No supported ciphers found"; then echo -e "\e[32mSecure\e[39m"; else echo -e "\e[31m\e[1mVulnerable\e[39m\e[0m"; fi

- A new POODLE-specific nmap NSE script:
- Recommended usage: nmap -sV --version-light --script ssl-poodle

- Accuvant nmap:
nmap -T3 -n -vvv -PN -sV --open --script=ssl-enum-ciphers -web-xml -oA POODLE_SCAN -iL targets.txt

openssl (HTTP): openssl s_client -ssl3 -connect [host]:[port]
openssl (non-HTTP): openssl s_client -starttls [smtp|pop3|imap|ftp|xmpp] -ssl3 -connect [host]:[port]

curl: curl -v -3 -X HEAD - a self-contained Bash script that can be used to scan internal resources that Qualys SSL Labs can't reach. Recommended. Use the -O option to specifically just test for POODLE.


Rapid7 Nexpose: (NOTE: requires both OS/platform update and signatures update):
- Note also that Nexpose interface itself now has SSLv3 disabled by default (can be re-enabled).
--- Add the following line to the file located at [INSTALLATION_PATH]/nsc/
--- com.rapid7.nexpose.nsc.sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv3"
--- Then restart Security Console.
Symantec Endpoint Protection (SEP): signature here:
Tenable Nessus:
- stunnel plugin
Trustwave TrustKeeper:
WhiteHat Sentinel:


Testing not yet supported, but may be soon:


Check Point has released IPS signatures:
Netwitness (RSA): detection support added to TLS-LUA parser.
Security Onion (general SSLv3 monitoring):
Snort rules:
HP Tippingpoint: none at this writing, but may show up in this search.


Apache/nginx syslogging, pcap extraction with tshark:

Mitigation and Remediation

Good general resources
Reddit thread (OK):
Good general cipher refs:
Excellent, detailed Mozilla reference with recommendations for many platforms:
- See also the awesome Mozilla SSL Config Generator:
BetterCrypto guide (PDF, excellent):

Server-side: Disable SSLv3.

Good lists of server howtos:

Adobe Connect:
Apache: SSLProtocol -SSLv3 -SSLv2
- An interesting script for disabling SSLv3 in many Apache configs:
AWS elastic load balancers:
IBM WebSphere:
Java Jetty:
lighttpd: ssl.use-sslv3 = "disable" - but only versions 1.4.29 or higher - see this bug:
Nginx: ssl_protocols TLSv1.2 TLSv1.1 TLSv1
Puppet (Enterprise, PuppetDB, MCollective):
Tomcat and JBoss Web:
Ubiquiti: patches in beta, or disable SSLv3 as noted here:
Also consider upgrade to OpenSSL 1.0.1j /1.0.0o / 0.9.8zc :
- Or apply OpenSSL patch (harder):

Very interesting idea: send anyone using SSLv3 to a help page: (idea from :

RewriteEngine On
RewriteCond %{SSL:SSL_PROTOCOL} ^SSLv3$
RewriteRule ^.*$ [L,R=302]

Example: (should redirect to site if your SSL client negotiates SSLv3)

Server-side (non-HTTP): Disable SSLv3.

Credit for some: StackExchange answer
Barracuda: For each "service" (site): Basic -> Services -> Edit -> SLL -> SSL Protocols, then click the Disable radio button for SSL 3.0 -> Save. See:
- May also need to upgrade to firmware
Dell: ?
Clearswift: ?
Courier: in /etc/courier-imap/pop3d.ssl and imapd-ssl, add !SSLV3 to TLS_CIPHER_LIST.
Dovecot: In /etc/dovecot/local.conf or /etc/dovecot/conf.d, ssl_protocols = !SSLv2 !SSLv3 - see
Mailborder: ? (no mention in docs, and this search has zero hits)
McAfee Email Gateway (MEG): (requires version 7.5.3 + HF971179 (3016.109) or later or 7.6.2H1008011 (3044.109) or later):
- Disable SSLv3: - Patches for OpenSSL pending:
Mimecast: not affected?
Postfix: smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
Proofpoint: ? (not clear; Sendmail-based, so might be feasible to modify an internal .mc file to use ServerSSLOptions and ClientSSLOptions to use the +SSL_OP_NO_SSLv3 command, but this may void warranties; consider opening a ticket with vendor)
SilverSky: ? (no mention on site, but this search may yield results someday)
WatchGuard: ?

Client-side: Disable SSLv3.

Good lists of client howtos:
Stack Exchange thread:

Web browsers - desktop

Firefox plugin:
Firefox client workaround: about:config -> security.tls.version.min = 1 (and make sure that max is 1 or more)
Chrome client workaround: command line flag --ssl-version-min=tls1
... on Mac OS, try:
Chrome and Chromium being updated to support the new fallback protection.
- but will be disabling SSLv3 fallback entirely in Chrome 39, and SSLv3 completely in Chrome 40:!topic/security-dev/Vnhy9aKM_l4
Internet Explorer: Internet Options -> Advanced tab -> uncheck 'SSLv3', make sure that TLS options are checked.
- or GPO:
Lynx: ? - other than disabling SSLv3 in the underlying OpenSSL, no clear remediation
Opera: upgrade.
- *very* interesting alternative method - "record splitting" - used by Opera team!
Safari: may be no way to disable?

Web browsers - mobile

Android: upgrade.
Blackberry: upgrade.
Chrome: update to latest; if older, see
Firefox: update to latest; if older, see link above
Opera: update to latest; if older, see link above

Operating systems

Apple OS X 10.10 Yosemite: fixed in this release, as per: and


Barracuda: upgrade to
- Disables SSLv3 in GUI, compiles in OpenSSL 1.0.1j with TSL_FALLBACK_CSCV, and now shows SSL protocol used in access and web firewall logs.
- Other information may show up in this search.
Blue Coat:
Cisco/Ironport: still under investigation by Cisco, see:
McAfee Web Gateway (MWG): - Policy -> Settings -> Engines -> SSL Scanner -> Default Certificate Verification -> SSL Protocol version ->
- Set 'Use SSL 3.0' to 'off'
- Set 'use alternative handshake settings after handshake failure' to 'off'
- See also this guide for both client-side and server-side approaches:
F5 Secure Web Gateway:
Squid: - sslproxy_options=NO_SSLv2 NO_SSLv3
Trend Micro InterScan:
Trustwave Secure Web Gateway (SWG):
Websense Content Gateway: uses SSLv3 by default. Be sure to enable TLS 1.1 and 1.2 (TLS 1.0 not recommended).
Zscaler: nothing yet, may show up in this search

Alternative: implement fallback protection (TLS_FALLBACK_SCSV) in your SSL stack.

OpenSSL patch:
... which implements TLS_FALLBACK_SCSV:

Many Linux distros will receive this automatically when OpenSSL is upgraded.

Alternative: record splitting

Opera: upgrade to get record splitting.
Other platforms: unknown

Alternative: patch to support TLS_FALLBACK_SCSV, disable all CBC ciphers, and enable RC4?

Preliminary research indicates that if RC4 and TLS_FALLBACK_SCSV are enabled, IE6 and IE8 on XP should still be able to connect. Note, however, that Ivan Ristic of SSL Labs does not recommend this approach.
- Ref:
- According to a post from Dr. Stephen Henson, core OpenSSL developer: "If you disable CBC ciphers then you're only left with GCM and RC4. RC4 can't be used with TLS and GCM is only supported in DTLS 1.2."
- Relevant thread:

It is claimed that you can disable all CBC ciphers, but I am not yet able to successfully do this. NOTE: It is up to you to determine the consequences for your user base. Preliminary research indicates that if RC4 is enabled, IE6 and IE8 on XP should still be able to connect.

To determine which CBC ciphers are supported is platform-dependent.


There is no way to disable all CBC ciphers that I am aware of; rather, you have to disable all of the ones supported by the current OpenSSL. This means that if others are added later, you must disable the new ones manually.

$ openssl ciphers | sed 's/:/\n/g'  | grep CBC | sort

Generating the list in cipher-disabling syntax (line breaks are artificial; this is one long string):

$ openssl ciphers | sed 's/:/\n/g'  | grep CBC | xargs | sed 's/ /:!/g;s/^/!/g'

Alternative: firewall controls



Vulnerable, or mixed:

- Safari (desktop):
- Apple TV:
Blue Coat: or search for CVE-2014-3566
Brocade (PDF):
CA: (just a "see our support site" blurb):
Canonical / Ubuntu:
Check Point: (IPS module info, and how to set minimum TLS version):
Cisco: most products with an HTTP web interface are likely affected.
cPanel: fixable, but Firefox won't do TLS on alternate ports?!
- See this forums post from cPanel staff:
- and the overall thread:
- See this thread:
- CentOS 6.x patches add support for TLS_FALLBACK_SCSV, but may not fix the overall POODLE vulnerability.
- TPAM Appliance:
FreeBSD: only affects OpenSSL in FreeBSD 10.
- VuXML:,
HP ILO: vulnerable, may never be patched; consider moving to isolated VLAN.
IPMI/BMC: probably none; consider isolating to separate VLAN.
Juniper:, or this search
McAfee Web Gateway: ?
- Exchange: same as general Microsoft above, then restart Exchange.
- IIS:
--- (or this simple .reg file)
--- (or use this free third-party widget to control IIS crypto:
- For all, note that TLS 1.1 and 1.2 not on by default in 2008R2 - see bottom of this post:
Nebula: disabled SSLv3.
- Patched OpenSSL:
- Patched PolarSSL: Opera (interesting mitigation!)
- Solaris 11.2 fix:
- Sign-in required:
- Oracle/Sun ILOM interfaces also run SSLv3, may be configurable; see
Parallels/Plesk: recommend disabling SSLv3.
pfSense: 2.1.x uses a vulnerable version of OpenSSL behind lighttpd, but no formal patch release yet (as of 2014-10-23 13:33)
- Manual patching (disables SSLv3):
- Forum thread:
Puppet: risk low, but recommend disabling SSLv3.
- backport of TLS_FALLBACK_SCSV:
Solarwinds: uses OS SSL stack, see your OS docs.
VMware: recommend disabling SSLv3.

Not vulnerable:

Responses (action taken by public services)

Accuvant: recommend disabling SSLv3.
Apple: disabled CBC ciphers under SSLv3 in Safari; no public statement.
Akamai: retiring SSLv3 by early November 2014:
- and
Amazon: recommend disabling SSLv3 in all clients and servers; upgraded to OpenSSL 1.0.1j in Linux AMIs; ELB no longer uses SSLv3.
- CloudFront howto:
Bitnami: recommend disabling SSLv3.
Blue Coat: recommend disabling SSLv3.
Cloudflare: disabled SSLv3.
DigitalOcean: recommend disabling SSLv3.
EFF / HTTPS Everywhere: disabled SSLv3.
Fastmail: disabled SSLv3.
FireEye: recommend disabling SSLv3.
Heroku: disabled SSLv3.
HP (Helion): disabled SSLv3.
Jenkins project infrastructure: disabled SSLv3.
Joyent: recommend disabling SSLv3.
Linode: disable SSLv3.
MaxCDN: disabled SSLv3.
Novell: recommend disabling SSLv3.
Palo Alto: recommend disabling SSLv3.
Paypal: likely to impact customers and APIs/embedded, but going to disable SSLv3 ASAP:
- OXID shopping cart PayPal fix:
Princeton: disabled SSLv3.
Rackspace: recommend disabling SSLv3:
RedHat: recommend disabling SSLv3:
Ruby: disabled SSLv3.
Slack: disabled SSLv3.
Suse: recommend disabling SSLv3:
Symantec: recommend disabling SSLv3:
Trend Micro: recommend disabling SSLv3:
Twitter: Disabled SSLv3.
UC Berkeley: disabled SSLv3.
Websense: recommend disabling SSLv3.
Zendesk: disabled SSLv3.


Pending. Once exploits are published, since the attack is a padding oracle attack might be relatively easy to detect by IDS, snort, etc. but I am not an expert in this area. - proof-of-concept code, not tested by me

Matthew Green (Johns Hopkins) has a pretty good narrative description of how exploitation would generally work:

News and posts

Ars Technica:
Dark Reading:
David Wheeler:
Errata Security:
Fedora Magazine:
Hacker News (good tech info):
Matthew Green:
Nikos M, GnuTLS author:
WhiteHat: Wikipedia:

Other similar summaries

Disable SSLv3 sites: |


Thanks to the folks who helped contribute to this document. So far, all contributors have waived the right to be individually credited.


If you see something missing, please let me know!

Return to The Story So Far (list of notable security events)