I have been meaning to get back on the blogging horse for some time, and what better way than with a new SSL vulnerability.
POODLE was announced this morning. It's a 5/10 on the panic scale, but both users and sysadmins should take action now.
This one isn't particularly exciting compared to the recent sky-is-falling heartbleed and shellshock - instead of giving away all your secrets and/or shell access to anyone with curl, the worst-case scenario with POODLE is that someone can read your SSL traffic; still bad, but for most people running small sites it's nowhere near the same scale.
Unlike shellshock and heartbleed though, this doesn't look like something which is likely to be fixed by a distro patch any time soon, because this vulnerability is inherent in SSLv3 (I'm no crypto expert, so I won't attempt to explain it myself). Because it is still used in the wild, distros are unlikely to disable it by default in the immediate future, so sysadmins will need to do something about it themselves.
This vulnerability doesn't come as a great surprise - SSLv3 is getting on a bit now, and was superseded by TLSv1 which has been supported by most browsers since IE6. However, most clients and servers are designed to fall back to earlier protocols if the newer ones fail - a good idea in theory, but in practice an attacker who wants you to use SSLv3 can force this to happen.
While this fallback strategy is likely to be disabled in future distro patches using
TLS_FALLBACK_SCSV, it will still leave any use of SSLv3 vulnerable. Although Google is using SCSV for maximum compatibility, based on Cloudflare's numbers where a trivial amount of valid traffic actually uses SSLv3, most people seem to be advocating the removal of SSLv3 altogether.
As a user you're vulnerable if you use SSLv3, so you should disable it - you're extremely unlikely to need it anyway. I won't go into details, but Mozilla will disable SSLv3 in Firefox 34, or you can disable it now in
about:config by setting
security.tls.version.min == 1.
Steps for sysadmins
Systems' traffic is vulnerable if they're running SSLv3, so a reasonable course of action would therefore be to disable SSLv3 at the top level of your server config, then re-enable it on specific sites if you get reports of problems - although it would be best to wait for a stable
TLS_FALLBACK_SCSV patch to land before re-enabling it.
Those running nginx can disable SSLv3 with Cloudflare's cipher configuration (add to
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5; ssl_prefer_server_ciphers on;
Apache users can add (to server or virtual host context):
SSLProtocol all -SSLv2 -SSLv3
And dirty IIS users get what they deserve - a 17 step procedure where you have to fiddle with the registry.
You should of course also take a look at any other services which are likely to support SSLv3, like mail or VPNs.
Testing your connection
As with heartbleed, Qualys SSL Labs seems to be the place to go for an easy and comprehensive assessment of your SSL security. Alternatively you could use openssl:
openssl s_client -connect [server]:[port] -ssl3
If you run that command and connect successfully, you're still vulnerable.