Saturday, June 6, 2009

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

8 comments:

  1. Hi,

    You might want to try Foundstone's SSLDigger for performing this benchmarking of SSL/TLS secure confguration.

    ReplyDelete
  2. Matthew,

    Thanks for the recommendation. I remember hearing about that tool a few years ago and had forgotten about it. I'll download it again and give it a try.

    ReplyDelete
  3. Well, I tried SSLDigger. It actually requires .Net 1.1. I tracked that down and installed it. But no luck. The program runs, but any attempt to check a website results in a Socket error being thrown. Oh well, the tool is old. Perhaps its not going to work with Vista.

    ReplyDelete
  4. What does work on Vista?

    ReplyDelete
  5. On windows:
    "sslciphercheck" : woanware checks supported SSL ciphers, it will also retrieve and extract the cert info including whether SGC is supported

    On Linux:
    the awesome openssl s_client command

    Regards,

    Han

    ReplyDelete
  6. Hello Michael,

    The aNULL cipher command can be used to check if the web server supports the use of anonymous ciphers (MITM issue):

    openssl s_client -connect hungariangirlinkrakow.pl:443 -cipher aNULL

    http://www.nessus.org/plugins.index.php?view=single&id=31705

    http://www.openssl.org/docs/apps/ciphers.html

    Greetz Han,

    PS. what happened to my certificate of completion :P (advance testing track @owasp krakow).

    ReplyDelete
  7. Han,

    Excellent point. The null cipher is a big issue. It essentially establishes an SSL connection which uses no encryption. So all data goes across in clear text.

    Thanks for the reminder on krakow. I'm checking into that.

    ReplyDelete
  8. There's a tool called sslscan that just is designed for a better scan and reporting of supported ciphers.

    ReplyDelete

Note: Only a member of this blog may post a comment.