2

I am currently in the process of upgrading the SSL certificates for various websites that I manage from SHA1 to SHA2 compatible certificates.

To date we have always used 'RSA' as the key exchange mechanism on our SSL certificates and therefore I decided to continue doing so when generating the Certificate Signing Request for the replacement certificates.

Within my development environment, I have replaced several certificates and prioritised SHA256 (SHA-2) based cipher suites on the web servers.

I have noticed that Google Chrome 42 and Firefox 37.0.2 are still selecting a SHA1 based cipher suite TLS_RSA_WITH_AES_256_CBC_SHA. (I have not properly tested Internet Explorer yet)

In order to determine which cipher suites Chrome 42 and Firefox 37.0.2 support, I have have performed a network trace and located the TLSCipherSuites within the ClientHello.

Chrome 42:

TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9E }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA { 0xC0,0x07 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_RC4_128_SHA { 0xC0,0x11 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9C }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
TLSCipherSuites: Unknown Cipher

Firefox 37.0.2:

TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }

Webserver

My webservers are running Windows Server 2008 R2 and supports the following cipher suites (note - this is the default preference order, I have since prioritised all SHA256 based suites:

TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA

The only SHA256 cipher suite present on Windows Server 2008 R2 that is supported by Chrome 42 and Firefox 37.0.2 is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (which in Server 2008 R2 has _P256 appended to the name). But in order to support this suite, I would have to reissue our certificates changing the key exchange mechanism from using RSA to ECDSA (Elliptic Curve Digital Signature Algorithm). I have in fact tried this and it works fine - but many older browsers do not support Elliptic Curve Cryptography. So this isn't a viable solution.

  • So it there a way to make Firefox and Chrome select a SHA256 cipher suite on a Windows Server 2008 R2 web server that does not break compatibility with older browsers?
  • Can additional cipher suites be added to the OS?


28/04/15 UPDATE:
Thanks to those who have answered for the added clarity regarding key-exchange algorithm and signature algorithm.

I would like browsers that are capable of using a SHA256 cipher suite performing message authentication using SHA2 to do so.

But the problem remains that of the available SHA256 cipher suites within Windows Server 2008 R2, the only one with support in both Chrome and Firefox is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. And in order to use this cipher suite, I require a ECDSA-signed certificate.

As I understand it, Elliptic Curve Cryptography lacks support on some older browsers/operating systems. As mentioned in my question (although I got the terminology wrong), I did create a ECDSA-signed certificate and although I have not done extensive testing, thus far I have seen that IE7 and IE8 running on Windows XP SP3 fail to load my sites (over HTTPS) and simply produce an "Internet Explorer cannot display the webpage" message.

Granted, Windows XP is now an obsolete OS but I'm concerned that browsers/operating systems that are 'old' but still 'supported' may fail in the same way. Therefore, I am interested in finding a solution using an RSA signed certificate - but that appears to be impossible. Am I right about this?

Community
  • 1
Fitzroy
  • 321
  • 2
  • 4
  • 8

3 Answers3

6

The SHA256 references you see in the ciphersuite lists are not for certificates. Rather they are related to the TLS pseudo-random function and message integrity.

Certificate support is independent of the TLS ciphersuite.

All versions of Firefox and Chrome (and recent versions of IE) support SHA256 certificates if the operating system also supports them, which for client Windows is XP SP3 and up. Server 2008 R2 has full SHA256 certificate support.

Richie Frame
  • 201
  • 1
  • 3
4

You don't want to be prioritising the SHA256 MAC algorithm over and above the other parts of the cipher suite. It is the least important part. The cipher suite you should have at the top of your priority list today on an IIS 7.5 server is:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

The critical parts to look for are;

  • The key exchange cipher (ECDHE is the best, elliptic curve for speed, Ephemeral Diffie-Hellman for forward secrecy)
  • RSA as the certificate signing algorithm - as you've discovered, the newer ECDSA certificates have compatibility problems with older clients
  • Symmetric cipher. AES GCM 128 bit is the best, but you can't have this and also keep ECDHE/RSA in Windows currently. The next best is AES CBC (either 128 or 256 bit).

You should use IIS Crypto (https://www.nartac.com/Products/IISCrypto/) and select the best practices option. This will give you the best cipher suite ordering that you can achieve in IIS currently.

See also my answer to this question:

Change Key exchange mechanism in IIS 8

Windows Server 2008 R2 enabled ciphers after applying IIS Crypto best practices:

Windows Server 2008 R2 enabled ciphers after applying IIS Crypto best practices

To obtain the server side list I generally use a compiled version of the code available here under "Listing Supported Cipher Suites";

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

I've uploaded a version I compiled to Dropbox if you wish to use it (at your own risk, I take no responsibility. But it's safe!)

https://www.dropbox.com/s/mvajmebtyilgics/listciphers.exe?dl=0

Community
  • 1
Steve365
  • 1,253
  • 9
  • 16
  • The cipher suite 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521' is not present on Windows Server 2008 R2. – Fitzroy Apr 29 '15 at 09:43
  • 1
    @Fitzroy Yes it is, it's just not enabled by default. See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx I'll update my answer with a screenshot showing the supported cipher list on one of my 2008 R2 boxes – Steve365 Apr 29 '15 at 10:46
  • How do I get hold of 'listciphers.exe', it doesn't appear to be a native Windows binary. It would be very useful to have a CLI tool capable of listing the cipher suites. – Fitzroy May 01 '15 at 11:04
  • @Fitzroy I've edited my answer. It's some code that Microsoft made available and I've compiled myself, use at your own risk, but it seems to work ok for me... :) – Steve365 May 01 '15 at 13:02
2

The answer by "Richie Frame" is spot on. It's not the SHA256 inside the signature that the cipher suite string refers to. But in addition to Richie's answer, here's an additional tidbit:

But in order to support this suite, I would have to reissue our certificates changing the key exchange mechanism from using 'RSA' to 'ECDSA' (Elliptic Curve Digital Signature Algorithm).

You can't do this. The session key exchange mechanism is not encoded inside the certificate itself.

You're mixing up key-exchange algorithm and signature algorithm. The confusion is because RSA can do both key-exchange and signatures.

It roughly breaks down like this:

  • For the old typical installation, you would have an RSA-signed cert and you'd do session key exchange via RSA as well.

  • For the newer type installation, you would have an RSA-signed cert and you'd do Diffie-Hellman session key exchange. And then authenticate that anonymous key exchange using the cert's RSA keys.

  • For the cutting edge type installation today, you would have an ECDSA-signed cert and you'd do Elliptic-Curve-Diffie-Hellman (ECDH) session key exchange. And then authenticate that anonymous key exchange using the cert's ECDSA keys.

Update 2015-04-29: Use sha256rsa cert

Therefore, I am interested in finding a solution using an RSA signed certificate - but that appears to be impossible. Am I right about this?

Nope. Fortunately you're wrong. You can use both in the same certificate. SHA256 as the one-way hash function and RSA as the signature algorithm. (This specific combination is codenamed "sha256WithRSAEncryption". But there are many others.) (Have a look at https://www.ietf.org/. They're using that exact combination right now.)

For compatibility, I recommend you read up on Ivan Ristić's blog.

Ivan Ristić, SHA1 deprecation: what you need to know (Archived here.)

One of the links in that blog is to the GlobalSign SHA-256 Compatibility table. That one might be particularly interesting for you.

Update 2015-04-29: You want something with "RSA_WITH"
If you've got an RSA cert, then you're using RSA-encryption. The encryption bit in the cipher suite descriptor string it the bit just before the "WITH".

So in your case you want something with "RSA_WITH" in the middle. I took these from the Firefox listing you made above:

TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }

And don't worry about the "SHA" or "SHA256" at the end of each string. This does not refer to what's in the certificate. It refers to the same algorithm but not to its application inside the certificate.

StackzOfZtuff
  • 1,754
  • 12
  • 21
  • Thank you for clarifying some of my misunderstandings. Please see my update to the question. – Fitzroy Apr 28 '15 at 19:35
  • I realise that I can use '_SHA256 as the one-way hash function and RSA as the signature algorithm_' - but I don't see a cipher suite in Windows Server 2008 R2 that's capable of utilising this combination and that's also supported by Firefox and Chrome. Can you point one out? – Fitzroy Apr 29 '15 at 10:35
  • "_And don't worry about the "SHA" or "SHA256" at the end of each string. This does not refer to what's in the certificate. It refers to the same algorithm but not to its application inside the certificate._" But if I want message authentication to occur over SHA2 then I'd have to use a cipher suite ending in 'SHA256', right? – Fitzroy Apr 29 '15 at 12:43
  • Yep. But from what I understand (and I don't understand the maths anymore at this point) then you'd even be alright with MD5 as your HMAC. Link with details: https://crypto.stackexchange.com/questions/6750/brute-forcing-an-hmac/6753#6753 – StackzOfZtuff Apr 29 '15 at 13:18
  • Yes AND no. Yes if it's a non GCM cipher suite. No, if it's a GCM cipher suite. Because in that case, just to be extra confusing, the SHA256 refers to the pseudorandom function and not the HMAC. Because GCM does not use a traditional MAC. -- But from a security standpoint even SHA1 as the MAC would be good enough. (Link with details on why HMAC-SHA1 is still safe enough: https://crypto.stackexchange.com/questions/6750/brute-forcing-an-hmac/6753#6753) – StackzOfZtuff Apr 29 '15 at 13:29