8

I am trying to configure IIS 8.5 on Windows 2012 R2 so that I do not get the notification from Chrome that the website is using obsolete cryptography. The image below is from Mac OS X , but I get a similar message in Windows 8.1 where the encryption algorithm is AES_256_CBC using a SHA1 hash and key exchange is ECDHE_RSA. The problem is the SHA1 message hashing. Google is trying to get websites to use SHA2 message hashing. On the Mac the algorithm used is SHA256 for hash signing but the problem here is the GCM modifier on AES encryption.

I have a new certificate that is 2048-bit RSA certificate supporting SHA256 message hashing.

I have used the NARTAC IIS Crypto tool to configure the IIS server. The Protocols Enabled are TLS 1.0, TLS 1.1 and TLS 1.2 The Ciphers Enabled are TripleDES 168, AES 12/128 and AES 256/256. The Hashes Enabled are SHA, SHA256, SHA384 and SHA512. The Key Exchanges Enabled are Diffie-Hellman, PKCS and ECDH. The SSL Cipher Suites Order for enabled suites are:

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_SHA256_P521 (it really is this way in the latest tool) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256

I have tried a large number of variations of this configuration, but none have resulted in a working site with the notification from Chrome gone. If I remove the AES 128/128 from the Ciphers Enabled it appears to have no impact. If I remove SHA from the Hashes Enabled then the website is unable to communicate with the SQL Server 2012 that provides data services to the website. If I remove the SHA1 based SSL Cipher Suites from the supported order then the browser is unable to connect to the server.

Has anyone got a working configuration of Windows IIS 8.5 with SQL Server, where the Chrome notification is gone?

John Davidson
  • 637
  • 5
  • 11
  • 1
    Do all of the *intermediate* certificates in the certificate chain use SHA256, too? What cipher suite does chrome actually end up saying it is using? – vcsjones Apr 08 '15 at 19:38
  • @vcjones no, 2 of the intermediate certificates are sha384, but the actual root is sha1. It looks like it is selecting the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 which is sha1 based. – John Davidson Apr 08 '15 at 23:24
  • SHA1 roots are ok. What version of SQL server are you using? – vcsjones Apr 08 '15 at 23:26
  • Also - are there and resources loaded from a 3rd party domain? Images, iframes, etc. are they all using correct cipher suites? – vcsjones Apr 08 '15 at 23:27
  • @vcjones I am using a mix of SQL 2008 and 2012. They both fail. I have tried creating a self-signed cert for the server just for SQL Server and have set the protocols to use that cert. That does not work. The self-cert I created does not specify any Key Usage. The CA provided cert specifies a Key Usage of Digital Signature, but I think it should be Key Exchange. The CSR generation wizard in IIS does not have a step to specify Key Usage. – John Davidson Apr 09 '15 at 00:05
  • @vsjones I have confirmed that the standard IIS is running page behaves the same in terms of ciphers. This page uses local resources. – John Davidson Apr 09 '15 at 00:08
  • Okay last question, then I think I'll have enough to tinker with this: are you using SSL to the SQL Server database? As in setting encrypt=true in the connection string? – vcsjones Apr 09 '15 at 00:18
  • @vcjones No, I had not tried encrypt=true in the connection string. I will try that now. – John Davidson Apr 09 '15 at 00:20
  • I don't think it'll help, I would expect it to only make the situation worse, but I suppose it can't hurt to try. – vcsjones Apr 09 '15 at 00:36
  • @vcsjones encrypt=true did not help. – John Davidson Apr 09 '15 at 01:23
  • @vcsjones I have concluded that this is actually a bug in Chrome and will be filing reports with them. – John Davidson Apr 09 '15 at 10:35
  • Using the Qualys SSL Lab reports it shows that the supported ciphers for Chrome do not match those normally available for IIS. There is a single cipher TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 that is considered an acceptable cipher by Chrome. However Qualys shows this as a weak cipher and it is not normally used by Windows. It has to be enabled and raised in priority for it to be used. 32-bit Chrome selects different ciphers for different pages with the web site. 64-bit Chrome never gets it right – John Davidson Apr 09 '15 at 10:44
  • DHE is "weak" unless you configure it to use 2048 DHE - and I am not sure that is possible in IIS. Using ECDHE is the right thing to do. It doesn't seem that IIS is picking up your selected cipher suites - how are you setting them? – vcsjones Apr 09 '15 at 14:23
  • @vcsjones If you look at the ciphers supported by Chrome (Qualys SSL Labs) most of the ECDHE ciphers except for SHA1-based are not an option for Chrome. Chromes primary ciphers are not supported by Microsoft at all. – John Davidson Apr 09 '15 at 21:13

2 Answers2

6

Windows Server 2012 does not appear to provide the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite needed to get rid of this error. See https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx for links to pages which list the cipher suites for the various versions of Server. You will note that Windows Server 2012 does have this cipher suite and I found that upgrading to 2016 was the best way for me to resolve the Google error. Please note that if you upgrade to Windows Server 2016 you will again need to use your IIS_Crypto 2.0 program to order the ciphers appropriately (or whatever ordering interface you choose). Using the Best Practices template will get you there. I chose their cipher order which yields TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at the top of the list.

Xavier Poinas
  • 19,377
  • 14
  • 63
  • 95
PrairieLark
  • 93
  • 1
  • 8
1

Either put TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 on top of the list or don't let the server override the cipher order presented by the client (which puts the preferred ciphers on top). I don't know if there is an option for this.

For more background about the issue see https://security.stackexchange.com/questions/85532/chrome-showing-cryptography-as-obsolete/85544#85544

Community
  • 1
  • 1
Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • I am having similar problem, and tried moving TLS_RSA_WITH_AES128_GCM_SHA256 to the top of my server's list, but this does not fix the problem either. However, it did change the client-server negotiation, Chrome reports it's using: TLS1.2, AES_128_GCM for encryption and authentication and RSA for key exchange. But Chrome still doesn't like it. Thanks, Google! – BobHy May 06 '15 at 11:40
  • @BobHy: It must be an ECDHE GCM cipher. Updated the response accordingly. – Steffen Ullrich May 06 '15 at 15:41