Windows Server 2008 R2 – SHA2 based Cipher Suites

certificatetls

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?

Best Answer

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.

Related Solutions

Ssl – None of the cipher suites supported by the client application are supported by the server

Windows 7 uses the new CNG (Cryptography Next Generation) API when choosing ciphers. CNG for Windows 2003 is not available as far as I know.

You can however, install these AES based cipher suites for use on Windows 2003:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

These are the first suites Windows Vista and Windows 7 clients will try to negotiate for use with TLS 1.0 and above, and are also supported by OpenSSL clients.

In order to use these, install KB948963

SSLCipherSuite – Disable Weak Encryption, CBC Cipher, and MD5 Algorithm

If their only complaint is MD5-based MAC, you should be able to simply add the !MD5 element to your existing cipher suite to meet the recommendation.

That said, I see they complain about the use of the CBC mode as well. Unfortunately, there is no CBC cipher group. The recommendation given to you also does not exclude CBC mode cipherspecs, at least on my version of openSSL (1.0.1e). This is a shame. If you need all such ciphers to be excluded, you could exclude all the CBC ones explicitly, though you will have to update that as they are included. Note that even HIGH includes CBC ciphers.

Including both ALL and RC4+RSA is redundant. I would be loathe to trust a security consultant (even a computerized one) that cannot even construct a well-formed cipherspec that meets their own recommendations.

The SSLCipherSuite takes an OpenSSL cipher spec. You can find this in the openssl documentation (link), but I find that this documentation is usually quite out of date. However, you can test one by running openssl ciphers ${cipherspec} on your server; output will be a :-separated list of ciphers that would be allowed by the given spec, or an error indicating none were allowed.

Similarly, if you want to know what LOW contains, do:

falcon@tiernyn ~ $ openssl ciphers 'LOW'
EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:ADH-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5

!LOW means to exclude those ones. +HIGH means to prefer the high-security ones in the ordering.

If you want a line-delimited list of all the ciphers that use CBC in your cipherspec, do:

openssl ciphers ${cipherspec} | sed 's/:/\n/g' | grep CBC

Those are the ones you'd have to exclude. You may, however, find it more reasonable to grep -v CBC and include only those (just set them up in a :-delimited list and use that as the cipherspec).