An analysis of a server offering encrypted communication should always included test for the security of the encryption. Things that spring to mind are of course if the encryption algorithms used are strong enough to withstand a cryptanalysis. So everything under 128 bit should definitely be considered weak. The testing for this can of course be done with openssl s_client –connect [-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1] servername:443. So for going through all the tests (protocol versions times all supported ciphers) you should either script something up or go for tools like sslscan or for windows thc ssl check.

Note: these tools just test for the normal used cipher suites and you will never end up with a complete picture of all the supported ciphers. So going back to manual testing depends if you find something or not with these tools and how far you want to go.

Next thing should of course be to test for weak protocol versions namely SSLv2. Although for SSLv3 there are now also known public weaknesses.

For the testing approach the same techniques as for the weak cipher lengths can be used.

Things that might not spring to mind at a first glance - but should definitely be tested for - are key exchange and renegotiation support.

Key exchange: The security of the communication relies heavily on the key exchange phase. If the exchange has weaknesses an attacker would not need to attack the cipher as he already got the key. Therefore the certificate of the server should be analyzed if the public key has the appropriate strength. Every key length under 1024 bits should be considered weak. Acceptable for new certificates should only be 2048 or even better 4096 bits. Testing for it is easy. Just download the certificate from the server and look at the public key.

Renegotiation support: Basically the renegotiation support with in the TLS protocol allows a man in the middle attack. Not the easiest to exploit but it could allow an attacker to insert traffic in an encrypted channel. In short an attacker sets up a encrypted channel with a server and renegotiates it to be used between the victim and server.

This can be tested again with openssl s_client -connect servername:443 and then

HEAD / HTTP/1.0

R

The single R in a line should do the trick. If the http request gets completed the server is vulnerable.

The last thing that springs to mind for testing ssl is if the certificate is in the right format and is valid. So nothing like a self signed certificate or wrong name or live time expired.

This should give a more complete picture of ssl testing.