title: SSL v3 vulnerable, kill it now link: https://onemoretech.wordpress.com/2014/10/15/ssl-v3-vulnerable-kill-it-now/ author: phil2nc description: post_id: 8658 created: 2014/10/15 12:07:30 created_gmt: 2014/10/15 16:07:30 comment_status: closed post_name: ssl-v3-vulnerable-kill-it-now status: publish post_type: post

SSL v3 vulnerable, kill it now

CVE-2014-3566 "POODLE" (Padding Oracle On Downgraded Legacy Encryption) is an exploit leveraging the (long deprecated) SSLv3.0 protocol that is embedded in every web server and web browser. This is another serious flaw that impacts pretty much everyone. UPDATED 2014/10/16. The exploit was discovered by Bodo Möller, Thai Duong and Krzysztof Kotowicz of Google. See their blog post here. The original security advisory was written in September but the details embargoed until yesterday to give time for vendors to come up with solutions. Darren Pauli has written a terrific piece over at The Register entitled "Kill SSL 3.0 NOW god dammit NOW: HTTPS SAVAGED by vicious POODLE". He quotes from the Googler's advisory:

To work with legacy servers, many TLS clients implement a downgrade dance: in a first handshake attempt, offer the highest protocol version supported by the client; if this handshake fails, retry (possibly repeatedly) with earlier protocol versions. Unlike proper protocol version negotiation (if the client offers TLS 1.2, the server may respond with, say, TLS 1.0), this downgrade can also be triggered by network glitches, or by active attackers. So if an attacker that controls the network between the client and the server interferes with any attempted handshake offering TLS 1.0 or later, such clients will readily confine themselves to SSL 3.0.

The basic recommendation is to disable SSLv2 and v3 support in all products (forcing the use of TLS and SSL v1, 1.1 and 1.2). This will, unfortunately, cause older web browsers such as IE 6 to fail -- but anyone still running IE 6 has worse problems already so in my opinion that shouldn't deter anyone from taking action immediately. Red Hat's security team has put out their own interim discussion with remediation advice for specific products (like Apache's HTTP and Tomcat server, and Firefox and Google's browsers), POODLE: SSLv3 vulnerability (CVE-2014-3566). Most of that advice is applicable to the same software from other vendors. For example, to secure the Apache web server all you need to do is edit ssl.conf and enable all protocols except SSLv2 and v3 with the line:

SSLProtocol All -SSLv2 -SSLv3

This issue is being tracked as Bug 1152786 on Red Hat's Bugzilla. Browsers can likewise be secured by going into preferences and removing support for these protocols. For Firefox the Red Hat advisory recommends going into about:config and changing the value of security.tls.version.min from 0 (TLSv3) to 1 (TLSv1). Background for these settings can be found in Security.tls.version.* on MozillaZine. There's an article on the Mozilla blog advising that SSLv3 will be gone as of Firefox 34 and that Firefox 35 will support SCSV downgrade protection. Ludo Poitou of the OpenDJ project has published an article on disabling SSLv3 in OpenDJ, entitled POODLE SSL Bug and OpenDJ. A nice page that provides good information on POODLE for technical and non-technical users is https://zmap.io/sslv3. In addition to configuration advice for both servers and browsers, it provides a simple test to determine if a browser is vulnerable: The zmap.io site also has some good statistics on sites that even at this late date in the decade do not support TLS, but rather force users to transact business with them over insecure SSLv3 (for example, citibank.com). Of course none of this would be necessary if these deprecated protocols had been removed from the code base when it became clear they weren't going to be adopted. Addendum: Here's a simple one-liner that can be used on any Unix or Unix-like machine (Linux, FreeBSD, MacOS) to see if SSLv3 is enabled:

openssl s_client -connect server.example.com:443 -ssl3

This will work with protocols other than HTTPS. For example, to test an LDAPS server:

openssl s_client -connect server.example.com:636 -ssl3

If the protocol is not available the message that comes back will include the warning "Secure Renegotiation IS NOT supported". Red Hat's security team has made available the following script for testing to see if a web server is vulnerable to this exploit:

#!/bin/bash
ret=$(echo Q | timeout 5 openssl s_client -connect "${1-`hostname`}:${2-443}" -ssl3 2> /dev/null)
if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
  if echo "${ret}" | grep -q 'Cipher.*0000'; then
    echo "SSL 3.0 disabled"
  else
    echo "SSL 3.0 enabled"
 fi
else
  echo "SSL disabled or other error"
fi

Copyright 2004-2019 Phil Lembo