I recently did an internal presentation on POODLE – what the flaw is and how to test for it – and a version of the slides can be found here. Obviously much has been written about the vulnerability, its mitigations and what the future holds. What follows expands on the testing aspect of the presentation, with a few pointers on manual checks if you feel you need to verify or clarify – and possibly even add to – what the tools are telling you.
SSLv3 support with block ciphers (in CBC mode) supported
All SSL/TLS tools check for SSLv3 support. You can do this manually with:
openssl s_client -ssl3 –connect <host>:443
This confirms SSLv3 support but obviously it only reports 1 cipher suite. This is where the tools come in. However, remember that POODLE only affects block ciphers in cipher block chaining (CBC) mode (which I’ll just abbreviate to “block ciphers” now, as I believe all the block ciphers that can run under SSLv3 operate in CBC mode). So review the list of supported cipher suites: if the server only supports RC4 ciphers then don’t report POODLE as an issue (instead report SSLv3, which is still old and creaky, and RC4!).
Even if the server supports block ciphers, it may prefer RC4-based ciphers so the likelihood of exploitation is going to be negligible. I recently wrote up what to do if you find that your tools disagree over which cipher suite is preferered.
I also recently posted in detail about how the TLS_FALLBACK_SCSV remediation worked. In short it’s a signal to the server from the client that it is connecting with a lower protocol version than it supports. If the server supports something better, then that should have been negotiated during the earlier connection attempts, so the server can abort the connection as being suspicious.
With the release of OpenSSL v1.0.1j it’s easy to test for TLS_FALLBACK_SCSV support:
openssl s_client -ssl3 -fallback_scsv -connect <host>:443
This is telling the server than I’d like to connect using SSLv3 – but grudgingly. I’m using
-ssl3 in the context of POODLE but TLS_FALLBACK_SCSV offers wider protection than this (checking support for it will continue to be worthwhile long after we’ve forgotten about POODLE.) Below you can see the fake cipher suite value advertising the fallback (which Wireshark couldn’t decode into something meaningful as it didn’t recognise the new cipher suite value 0×5600 at the time):
If the OpenSSL connection succeeds as usual (as shown below – a cipher suite has been chosen) then the server doesn’t support TLS_FALLBACK_SCSV.
If the connection fails with the new
inappropriate_fallback alert then the server does support TLS_FALLBACK_SCSV:
Enabling TLS_FALLBACK_SCSV is all very well but it does depend on client support too – so if the server has SSLv3 enabled with block ciphers supported (and preferred) then it’s not out of the woods. A few browsers do already support it – Chrome 33 (Feb 2014), Firefox 35 (Jan 2015), Opera 25 (Oct 2014) – so it’s better than nothing, and of course support for it among browsers will only improve. Acknowledging TLS_FALLBACK_SCSV support is therefore worthwhile – both today and in the future. A client may even feel aggrieved if they’ve gone to the trouble of enabling TLS_FALLBACK_SCSV but get no credit for it in their pentest report!