With the recent interest in TLS, due to Heartbleed and the concerns about privacy due to the actions of certain agencies responsible for national security, there has been some really good discussion about TLS and how it is implemented. Many people have talked about cipher suites in the context of server configuration. Basically they have talked about how to set up your servers to only use secure protocols(no SSLv2, and no SSLv3 if you can get away with it), secure key exchange(preferring Perfect Forward Secrecy mechanisms), secure symmetric ciphers(AES-GCM, AES-CBC, and 3-DES if you have to) and good integrity checks a.k.a. HMACs(e.g. not using MD5, SHA-1). While I love this discussion and am glad it seems to be getting moving in the right direction, I think it is also important to talk about what is going on with clients. The configuration of my servers is important to the people who connect to my servers(all twelve of you), but it doesn’t affect the rest of my web browsing. If I’m on my banks website browsing with IE8 on Windows XP, the security of my web server configuration doesn’t make me any more secure :). In this article I am going to talk about which cipher suites the different browsers support, how they negotiate, and I will speculate a bit on the different design decisions made by each vendor. I will also list whether Server Name Indication is supported or not. This isn’t really a feature that improves security per sé, but it is important in terms of moving things forward as IPv4 addresses get more and more scarce.
I did not test all clients in the table above and in the cases of IE8 and both versions of Java, I relied on documentation that I have listed in the references at the bottom of this article instead. I did not test Safari as they no longer support Windows and you can’t run it on Linux 😉 and it seems that they don’t have it documented anywhere. I did not test mobile devices as there are a lot more permutations and combinations involved in mobile. I was shocked that Mozilla and Google did not have information about cipher suites in their developer documentation. With the clients that I tested, I used the DSSEC research group’s SSL cipher suite details site, but I could have just as easily sniffed Client Hello with Wireshark.
Internet Explorer is a bit of an oddity as Microsoft has chosen to tie it’s crypto subsystem to the operating system rather than it being tied to the browser. What this means is that IE8 on Windows XP supports different cipher suites than IE8 on Windows 7, for example. Having said that, it was a very pleasant surprise to see how well Internet Explorer 11 on Windows 8.1 scored. Microsoft has done a pretty good job finding the right balance between security and compatibility. IE 11 was not only the only client that implemented AES-GCM 256-bit, but also the only one to deprecate RC4 and MD5. In my opinion if Microsoft can drop support for RC4 and MD5 I don’t see why Chrome, Firefox and Java would still need it. Chrome and Firefox do support AES-CBC 256-bit but for AES-GCM they only support 128-bit. Chrome now supports ChaCha20 which is an up and coming stream cipher optimized for software implementations when AES acceleration is not available in hardware and RC4 is not desired or supported. Firefox and Java both support Camellia which I must admit, I had never heard of.
Photo Credit: Mike