Google has announced the discovery of a protocol vulnerability in SSLv3. This vulnerability allows an attacker to read contents of connections secured by SSLv3.
SSLv3 is a Secure Sockets Layer (SSL) protocol that has been ratified in 1996. SSL is used to encrypt communications between clients and servers. It is usually integrated with webservers, mailservers or other software that use secure communications.
SSLv3 has been succeeded by TLS v1.0 in 1999 and later by TLS v1.1 and v1.2 in 2006 and 2008 respectively. SSLv3 is still supported on most servers for backward compatibility with old clients that have no TLS support such as Internet Explorer 6.
What is the vulnerability?
An attacker can perform a man-in-the-middle attack on SSLv3. This attack consists of two steps
- Make sure the client and server agree on using SSLv3
- Exploit protocol vulnerabilities in SSLv3 to obtain plaintext traffic
The original paper describing the attack can be found here: https://www.openssl.org/~bodo/ssl-poodle.pdf
The vulnerability is assigned CVE reference 2014-3566
Are you affected?
All software supporting SSLv3 is affected by this vulnerability. To see if your servers support the SSLv3 protocol we recommend to following tools to scan your websites:
- Qualys ssltest: https://ssllabs.com/ssltest
- SSLyze: https://github.com/nabla-c0d3/sslyze
- SSLScan: http://sourceforge.net/projects/sslscan/
You can test your server by using the following OpenSSL command:
openssl s_client -ssl3 -connect [host]:[port]
For services using STARTTLS such as SMTP, POP3 and IMAP you need to add the -starttls option:
openssl s_client -starttls [smtp|pop3|imap|ftp|xmpp] -ssl3 -connect [host]:[port]
If the server does not support SSLv3 you should see a SSL alert similar to this:
SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/xx/src/ssl/s3_pkt.c:1125:SSL alert number 40 SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/xx/src/ssl/s3_pkt.c:546:
Or you can use the following Nmap command (does not support STARTTLS):
nmap --script ssl-enum-ciphers -p [port] [host or subnet]
If the server does not support SSLv3 you should see output similar to this:
| ssl-enum-ciphers: | SSLv3: No supported ciphers found
As a system admin – what can I do?
- Disable the SSLv3 protocol on your servers (Web, SMTP, VPN,..). We recommend the following guide about deploying SSL/TLS: https://www.ssllabs.com/projects/best-practices/
- Disabling SSLv3 on your servers could impact older operating systems and clients, such as Internet Explorer 6 users on Windows XP and some older versions of Java.
- Instructions for disabling SSLv3 on Nginx and Apache: https://wiki.mozilla.org/Security/Server_Side_TLS
- Instruction on securing Microsoft Internet Information Services (IIS) see the following Microsoft knowledge base article on disabling SSLv3: http://support2.microsoft.com/kb/187498/en-us
- Instructions for Postfix, HAProxy: http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
As a consumer – what can I do?
See the following blogpost by Zmap.io for information how to disable clientside SSLv3 for the most popular browsers: https://zmap.io/sslv3/
Detecting SSLv3 usage in your network
You can identify servers that still use SSLv3 in your network only when an SSLv3 connection is successfully negotiated using the following IDS signature:
Note: The following rule only detects the usage of SSLv3 on servers, not clients. It makes use of the Snort SSL preprocessor (http://manual.snort.org/node147.html), please make sure the ports you want to monitor are listed in both the preprocessor config and the signature. Servers can still be vulnerable if SSLv3 is enabled but no clients make use of SSLv3 towards the server, the rule only triggers if SSLv3 is successfully negotiated.
alert tcp $HOME_NET [443,465,993,995,25] -> any any (msg:"FOX-SRT - SSLv3 Server Hello Detected (Poodle)"; flow:established,to_client; ssl_version:sslv3; ssl_state:server_hello; content:"|16 03 00|"; depth:3; threshold: type limit, track by_src, seconds 300, count 1; reference:cve,2014-3566; classtype:policy-violation; reference:url,http://blog.fox-it.com/2014/10/15/poodle/; sid:1; rev:2;)
Further reading
- POODLE Attack and SSLv3 support measurement: https://zmap.io/sslv3/
- Non-technical explanation of the vulnerability by Errata Security: http://blog.erratasec.com/2014/10/some-poodle-notes.html
- Technical explanation of the vulnerability by ImperialViolet: https://www.imperialviolet.org/2014/10/14/poodle.html
- Wikipedia article on TLS: http://en.wikipedia.org/wiki/Transport_Layer_Security
Browsertest shared by SANS: https://www.poodletest.com/
Here is an excellent explanation of the problem by one of the Chrome developers
https://www.imperialviolet.org/2014/10/14/poodle.html
One of the issues that will cause concern here is that we have slipped into saying “we use SSL encryption”, as it is what we have become used to saying. However, in most cases we actually mean “We are using TLS encryption”. As pointed out in the articles is the issues is largely caused when tricking TLS to fall back to SSL. The fix to prevent the fall back seems relatively easy, but will ‘break’ for people using IE6 – GOOD, perhaps this will force the issue on upgrading. In the light of the current threat landscape how long can we afford to pander to the legacy world – its hard enough protecting the current.
SSLscan is no longer actively developed. While your test case is valid I would suggest to use alternatives like sslyze.