So you point a SSL/TLS scanner to your secure web server and see what cipher suites and protocols will be listed as supported ?
Let’s take a look at SSL Scan, a pretty popular SSL/TLS server scanner.
Say I go to one of eBay's servers(we’re not interested in the server itself, just in its SSL/TLS settings, Amazon’s servers might serve as a good example too) and:
Hmmm…
Something does not look right here…
Let’s try one more time adding the --http option:
So what do we have here ?
It looks like an interesting way of saying that SSL 2.0 or certain SSL 3.0/TLS 1.0 cipher suites are not supported by the server.
We can complete some certain SSL/TLS handshakes with this server, but this does not mean we can actually send some data(say HTTP requests) using these SSL/TLS sessions.
The OpenSSL s_client is our buddy here, as it can play the “SSL/TLS telnet client” role.
- if we try with SSL 2.0, we get connected but when we issue a GET request, we got a “friendly” error saying that we use SSL 2.0 and the server does not support SSL 2.0.
- if we try with TLS 1.0 and a weak cipher suite, DES-based one, we get connected but when we issue a GET request, we got a “friendly” error saying that there are no common encryption algorithms between the client and the server, and we should check to see if we support SSL 3.0/TLS 1.0 and 128-bit encryption algorithms on the client.
For example, this error friendly behavior has been mentioned by Ivan Ristic here for Amazon servers and SSL 2.0, and by David J. Meier here(see the comments section) for eBay servers and SSL 2.0.
I’ve detailed it above for certain weak cipher suites too.
While the SSL 2.0 detection might be a little easier(after all there are only a few cipher suites and we can easily issue HTTP requests and log any errors returned), the one for certain SSL 3.0 and TLS 1.+ cipher suites(above we played for certain weak cipher suites) might get a little tricky, because there are quite a few cipher suites, and an implementation might not support all the cipher suites from a protocol version(to be actually able to complete a SSL/TLS handshake with the server in order to issue HTTP requests).
The approach used above with SSL Scan is useful, first we can scan without issuing any HTTP requests. If we suspect that something is fishy we can attempt to connect with SSL/TLS and issue HTTP requests, which may provide more accurate results.
The downside of SSL Scan is its dependency on OpenSSL, hence the limitation of protocols and cipher suites supported(although currently this might not be quite a problem, depending against what server we point it).
With SSL Labs, while the detection for SSL 2.0 is improved(as mentioned in the above link), not the same thing can be said about SSL 3.0 and TLS 1.0(as writing SSL Report v1.0.48) and certain weak cipher suites.
SSL Labs, similar with SSL Scan, logs the cipher suites accepted, also logs the protocols supported.
We can digest the SSL 2.0 part, but for example for TLS 1.0, if we correlate that TLS 1.0 is supported with the cipher suites listed, apparently TLS_RSA_WITH_DES_CBC_SHA will be supported, which is not the case.
The downside with SSL Labs in terms of accuracy is that sometimes isn’t clear what cipher suites were accepted and what cipher suites are actually supported, above certain weak cipher suites are the culprit:
