October 15, 2014
On 2014-10-14, a vulnerability in the SSLv3 protocol was published. This page is a public version of a blog post I put up at $WORK, to help employees understand the impact of the vulnerability on the company and you personally. It was added here upon request to share the information outside the company.
The latest reason to confirm that the internet is once again on fire is a vulnerability in version 3 of the Secure Sockets Layer protocol. This vulnerability is unlike the #heartbleed vulnerability we encountered earlier this year in that it is a flaw in the protocol, not the implementation of a specific library. As such, exploiting POODLE is more similar to the BEAST attack. It is noteworthy because of its widespread impact: every client and server that uses SSLv3 is affected, and the best solution is to turn off SSLv3 altogether. That, however, means that clients that can't speak TLS1.0 or higher will not be able to reach services which have SSLv3 turned off. Microsoft Internet Explorer 6 does not have support for TLS, and has thus been holding back widespread abandonment of SSLv3 despite its (other) known flaws. The name "POODLE" is a backronym for "Padding Oracle On Downgraded Legacy Encryption". This makes POODLE the first SSL vulnerability with its own emoji () -- crucial property in todays fast-paced world!
POODLE is a padding oracle attack on SSLv3, which uses cipher-block chaining (CBC). By making multiple requests with the partial cipher text an attacker may be able to retrieve the plaintext of, for example, an encrypted cookie. The details of how this is accomplished are well described on Adam Langley's always interesting blog.
A successful attack requires both parties, client and server, to speak SSLv3. Hence, a solution to protecting your services is by not allowing SSLv3 at all. Likewise, as a user, you can turn off SSLv3 in your clients (most notably your browser(s)).
From an end-user perspective, this is trivial: there are very few sites that actually require SSLv3, so turning off support for the old protocol should have no negative consequences for you.
For service owners, there is the risk of dropping some traffic due to ancient clients. As noted above, Internet Explorer 6 is the most notorious example of a client that's still in use and which doesn't support TLS. There may be others, however.
Since part of the attack vector is in forcing a downgrade of the encryption protocol, it is possible to prevent this attack by using the TLS_FALLBACK_SCSV mechanism in newer SSL libraries. This option, described here, has been included in the latest version of OpenSSL as of 2014-10-15.
You're right. Now is not the time to be nice to your POODLE. I'm afraid you have to put it down.
That is, your client should be configured to explicitly disable SSLv3. Remember, any tool you have that makes an https call (or an otherwise TLS/SSL protected request, such as for MTAs using STARTTLS), is a "client" in this context. Explicitly enforcing TLS rather than allowing SSLv3 will protect you.
In order to disable SSLv3 in Google Chrome, you need to invoke it with the --ssl-version-min=tls1 command-line option:
$ open /Applications/Google\ Chrome.app --args --ssl-version-min=tls1
If you are using Quicksilver or Alfred, you can write a simple AppleScript (do shell script "open /Applications/Google\\ Chrome.app --args --ssl-version-min=tls1") to start Chrome. (I currently don't know of any configuration setting you can use to have this be the default.)
Go to about:config and set security.tls.version.min to 1:
Visit https://poodletest.com. No, I'm serious.
curl --tlsv1 $URL
For example, the following call, failing to retrieve a vulnerable poodle, shows that your curl(1) correctly refuses to talk SSLv3:
$ curl -v -I --tlsv1 https://sslv3.dshield.org/vulnpoodle.png * Adding handle: conn: 0x7fde44003a00 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7fde44003a00) send_pipe: 1, recv_pipe: 0 * About to connect() to sslv3.dshield.org port 443 (#0) * Trying 220.127.116.11... * Connected to sslv3.dshield.org (18.104.22.168) port 443 (#0) * Could not negotiate an SSL cipher suite with the server * Closing connection 0 curl: (35) Could not negotiate an SSL cipher suite with the server
openssl s_client -no_ssl2 -no_ssl3 -connect $SITE:443
For example, the following call, failing to connect to an SSLv3 site, shows that your client correctly refuses to talk SSLv3:
$ openssl s_client -no_ssl3 -connect sslv3.dshield.org:443 CONNECTED(00000003) 10123:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s23_clnt.c:558: $
Here you go. I'm sure they all have hilarious dog photos, so if nothing else you get that:
October 15, 2014