5

Not really sure if this is the appropriate SE to post this to, but here it is: Is there some online reference for what SSL ciphers are supported by the various browsers? Basically, I'm interested in hardening systems by ensuring lower key lengths and old as dirt algorithms (DES and 3DES) aren't used for communication with the client.

The way to do this (at least with Apache mod_ssl) seems to be to control the supported ciphers the server gives during the handshake.

I want to be able to answer questions like "If I force AES256, which browsers will break?"

For some sites this is desirable as it gives us some guarantees as to the confidentiality of the conversation. If their browser only supports what is considered an insecure connection, we want the session to break so they're forced to use a more modern/robust client.

Bratchley
  • 231
  • 3
  • 15
  • 2
    You may want to contact the creator of this site, he may have statistics : https://cc.dcsec.uni-hannover.de/ – mveroone Aug 28 '13 at 13:55
  • 2
    I think you may have a misconception in thinking that web browsers alone are responsible for whether a system can use a particular cipher such as AES256. Browsers may support overarching protocols such as SSL 3.0, TLS 1.0, and TLS 1.1, but the underlying cipher suites are generally provided by the operating system or third-party DLLs. (Schannel.dll, Crypt32.dll, etc.) And other applications can even implement their own. – Ryan Ries Aug 28 '13 at 14:04
  • @RyanRies I'd imagine a lot of browsers probably dynamically link against host libraries, but farming the whole thing out to the platform seems like it would raise compatibility issues. I did test it after you mentioned it though, and on this same computer Firefox and Chrome both return very different results when visiting the page Kwaio linked. It appears Firefox supports a wider array of ciphers than Chrome does (which surprised me at first, until I thought about Firefox's age advantage/disadvantage). – Bratchley Aug 28 '13 at 14:10
  • @JoelDavis Cool! Welp, my interest is piqued. :) – Ryan Ries Aug 28 '13 at 14:11
  • 1
    If you get answers from him, (and with his approval) please pôst the results here, i'm intrested too ! – mveroone Aug 28 '13 at 14:13
  • Will do. Also if anyone who happens to be lurking this question knows, I'd like to hear it too, just in case he doesn't respond. – Bratchley Aug 28 '13 at 14:14

1 Answers1

2

Is this the right way to solve the problem?

All SSL/TLS server should (must?) provide a mechanism for specifying a ciphersuite preference and available ciphers: if you don't want to use insecure algorithms then don't configure them. Do give a higher priority to more stronger ciphers (if security is your priority).

Obviously we can't tell you what set of ciphers meet your security requirements. However maintaining a list of the ciphers supported in your clients browsers is a big task. And it's one which large companies like Google, Paypal, eBay and others actively undertake - why not just test what they are currently offering?

(do bear in mind that some sites will use HTTPS purely as a springboard to negotiating SPDY).

Community
  • 1
symcbean
  • 21,009
  • 1
  • 31
  • 52
  • 4
    "if you don't want to use insecure algorithms then don't configure them." That's basically what I'm attempting to do. The question is intended to find a resource that gives me the information required to balance security with compatibility. Public websites will typically prioritize compatibility and performance over most security. We can just tell people to use different clients so we're OK with them breaking, as long as they have enough alternatives to pick from when we do that (hence why knowing which browsers we break is important). – Bratchley Aug 28 '13 at 14:58