Today a colleague of mine asked me if I really thought one could tell what cipher strength is used during SSL transactions. I said sure! Piece of cake if you know what to look for. Just like in the movie Matrix, if you stare at the cipher text long enough you visualize the meaning and a little voice in your head tells you “AES-256…..” or “ECDHE….” or “They are out to get you…..”
Well ok not really..but you can easily find out and here’s how. When a client like IE connects to a web server that supports SSL there’s a handshake message called ClientHello. In this message the client bares all and lists all of the cipher suites that it supports. See the example below for an example ClientHello message…and look very carefully.
If you are used to seeing ClientHello messages, two things should appear somewhat odd in the image above. I captured it during an IE8/Windows 7 handshake with an IIS 7.5 web server. First, the client supports TLS 1.2. This is unusual, and takes manual intervention to enable in IE8. Second, the order of the cipher suites is non-standard as well. I didn’t like the default order that Microsoft bakes into Windows so I put the AES-256/SHA-256 cipher suites at the top of the list. Nothing but the best!
Now how about the server end? Astonishingly there’s a server message called ServerHello. Servers are busy beasts, so all it returns is the strongest cipher suite that it has in common with the client. In this case I also enabled TLS 1.2 on the server end, so it picked AES-256 with SHA-256.
From there on out the SSL handshake continues and eventually an encrypted session is built up and all comms go secure. You can apply the same sniffing techniques to deconstructing SQL SSL sessions as well. Network Monitor 3.4 seems better than WireShark at decoding more types of SSL connections, such as those used by SQL.
You could also use: http://downloads.sourceforge.net/project/sslscan/sslscan/. I tend to use this on FreeBSD.
-Alex