This year will surely be reminded as a year in which really serious vulnerabilities were discovered. It started in April with Heartbleed which was the one that exposed the private key used in the services running with OpenSSL as the protocol to encrypt communications, with that meaning that sysadmins needed not only to fix the bug but also to replace the certificates installed as they weren’t to be trusted anymore.
Later on, in the last days of September, an extremely serious bug was found in Bash, which enabled attackers to run remote commands on the vulnerable systems. This one was given the name of Shellshock and it was as severe as easy to exploit. The funny thing? It was present since 1994.
On Tuesday 14th October, Poodle vulnerability was revealed by some guys at Google. In few words, with this bug an attacker can calculate the original plaintext message when encrypted with SSLv3, which makes encryption with that protocol absolutely useless.
For now, the recommendation is to completely disable SSLv3 on every server using it and use TLS 1.1 and 1.2 instead. With this action taken by sysadmins (and soon by client software) SSLv3 is probably facing its end.
Client software should also be configured to not use SSLv3 in order to protect clients from servers which may still be using SSLv3.
How to test for SSLv3?
You should try both servers and clients to see if they are vulnerables to Poodle vulnerability.
To test if SSLv3 is enabled in a server you could simply execute:
$ openssl s_client -connect HOTS:PORT -ssl3 CONNECTED(00000003) 7208:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:1125:SSL alert number 40 7208:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:546:
By looking at the command executed above and its result one can conclude that the server doesn’t have support for SSLv3. In the case the connection succeds then SSLv3 is enabled.
Another way to try it is using nmap:
nmap --script ssl-enum-ciphers HOST ... 995/tcp open pop3s | ssl-enum-ciphers: | SSLv3 | Ciphers (3) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | Compressors (1) | NULL ...
In the output above nmap lists all cipher protocols supported by the server and in this case it says that in port TCP 995 a service using SSLv3 is running.
Testing web browsers
There are different sites to test web browsers, two of them are zmap.io and Poodle test. If your browser is vulnerable (which probably is) there are instructions on how to disable SSLv3 for almost every major web browser at zmap.io site.
The good thing to notice
Regarding the first two vulnerabilities, open source community reacted very quickly and a patch for most operating systems was released as soon as they were announced. With Poodle vulnerability, instructions on how to test and disable SSLv3 in most open source software was released with little delay.
On the other hand, I had to manually compile bash on my Mac to avoid the Shellshock vulnerability as Apple took some time to release a fix for it. The same happens now with Poodle vulnerability as workarounds exists for major web browsers but none for Safari (at least at the moment I’m writing this).
UPDATE: I have updated Safari and it’s now protected from Poodle.