Testing with OpenSSL

In addition to creating your own certificates, OpenSSL provides several useful features for security testing. One of my favorites is the s_client command. This command tells openssl to establish a connection with a site. If you add on the cipher argument, you can specify what level of ciphers to use when establishing the SSL connection. Interesting note: many of the largest banks still support weak DES encryption for connections to their web server. More on this in a few.

Here's the command:
openssl s_client -connect site.com:443 -cipher LOW

The cipher argument accepts NULL, LOW, MEDIUM, HIGH and FIPS.

The NULL cipher setting simply means that an SSL connection is established, but the data is sent across in clear text. This is obviously bad.

If you are curious about what ciphers are included in each of these categories, then just run the following command:
openssl ciphers LOW -v

FYI, for those looking for a list of FIPS approved ciphers, here they are (add -v for more info):
>openssl ciphers FIPS
ADH-AES256-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
AES256-SHA
ADH-AES128-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
AES128-SHA
ADH-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
DES-CBC3-SHA (note: this is actually 3des, add -v to see this info)


Now, lets discuss the impact of a server supporting weak ciphers. The main threat is a cipher downgrade attack. In this attack a man-in-the-middle tampers with the initial messages sent by the client to establish the SSL connection with the server. During these first few packets the client and server are exchanging a list of ciphers which they each support. If the client were to say, I only support DES-CBC-MD5 (weak cipher!), then the server has two options. One, drop the connection because no ciphers are mutually supported. Or two, provide support for that cipher and begin an encrypted session with the weak DES-CBC-MD5. In scenario two the user would have a normal SSL connection with the server, nice little HTTPS in the url and everything would be great. Except for one thing, DES would be the encryption algorithm used for protecting the data in transit. At this point an attacker could capture the stream of data and break the DES encryption offline at their leisure.

Should you be concerned that you may be a victim of this attack? If you are using a recent version of any browser then the answer is no. Luckily modern browsers have removed weak ciphers almost entirely. To see what ciphers are supported by your browser you can setup openssl as a server and connect to it. This is a bit more complex and requires a server cert and private key. Perhaps another post is needed to explain how to create those items.

openssl s_server -www -cert cacert.pem -key cakey.pem

Connect to the openSSL server at https://127.0.0.1:4433/ and the returned page will show a bunch of stuff including the following:

Ciphers common between both SSL end points:
DHE-RSA-AES256-SHA         DHE-DSS-AES256-SHA         AES256-SHA             
DHE-RSA-AES128-SHA         DHE-DSS-AES128-SHA         RC4-MD5                
RC4-SHA                    AES128-SHA                 EDH-RSA-DES-CBC3-SHA   
EDH-DSS-DES-CBC3-SHA       DES-CBC3-SHA

So you can see that the webbrowser used for this test (Firefox 3.0.5) only supports stronger ciphers. If you weren't convinced, just rerun the server command and specify -cipher LOW. If a connection is established, then you know the browser supports weak ciphers. If your browser does not support weak ciphers, then you should get the error message similar to:

Cannot communicate securely with peer: no common encryption algorithm(s)

Now, one final point is left to discuss. If modern browsers don't support weak ciphers, then why should we care about this at all. The answer is because plenty of applications are being designed to automatically connect to webservers and perform some sort of automated operations. During design a decesion must be mage regarding what ciphers will be support for SSL connections. If the custom application and the server both support weak ciphers (in addition to the strong ones), then there is a risk for a man in the middle cipher downgrade attack.

To wrap things up, don't just assume that because you are using SSL you are actually using a strong encryption. Make sure the client and server are both configured to only allow strong ciphers.

FYI, this is a very common problem. I took a look at several of the top banking websites and most of them support LOW ciphers. So you can thank your browsers for removing weak ciphers and protecting you on this one.

-Michael Coates