How to configure IIS 7.5 SSL \ TLS to work with iOS 9 ATS

Question

Problem: Our mobile app can no longer establish a secure connection to our web-service since iOS 9 now uses ATS.

Background: iOS 9 introduces App Transport Security

Server Setup: Windows Server 2008 R2 SP1 (VM) IIS 7.5, SSL certs from digicert. Windows firewall off.

Key RSA 2048 bits (e 65537)

Issuer DigiCert SHA2 Secure Server CA

Signature algorithm SHA512withRSA

These are the App Transport Security requirements:

The server must support at least Transport Layer Security (TLS) protocol version 1.2. Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.) Certificates must be signed using a SHA256 or better signature hash algorithm, with either a 2048 bit or greater RSA key or a 256 bit or greater Elliptic-Curve (ECC) key. Invalid certificates result in a hard failure and no connection. These are the accepted ciphers:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

What has been tried:

1. Adding exceptions in the mobile app to allow our domain works, but I do not want to go with this unsecured method, I want to fix our SSL.
2. Used IIS Crypto to use 'best practice', tried 'pci', and custom setups. Even tried modifying the crypto suite to just the list above, and reordering. After each attempt, server is rebooted, and and SSL Labs was ran (after clearing cache). I was successful at going from a F rating to an A, and even A-, but this only resulted in iOS 8 and 9 being unable to establish secure connections. (NSURLErrorDomain Code=-1200 and _kCFStreamErrorCodeKey=-9806)
3. Restored VM and tried a powershell script Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2 I even made a second attempt where I edited out cyphers from the power script to a minimal list of what is required.

Results: Always similar, ratings of A or A-. iOS8 and iOS9 can't negotiate secure connection. Handshake Simulation results in "Protocol or cipher suite mismatch" for Safari and iOS products.

UPDATE After working with Apple support, we did some packet trace capture:

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

The first three packets are the classic SYN - SYN-ACK - ACK three way handshake that sets up the TCP connection. The fourth packet is iOS sending your server a TLS Client Hello message, the first step in setting up a TLS connection over that TCP connection. I’ve pulled apart this message and it looks reasonable enough. In the fifth packet the server simply drops the connection (by sending a RST).

Does anyone know why IIS 7.5 would be doing a RST?

Answer 1

The question is old, but it will be found during searching. I spent some time to find solution to the same problem. Thus I decide to write the answer to share my results with others.

Short answer: you should not use IIS Crypto to specify the order of Cipher Suites. I recommend you to click on "Defaults" buttons to remove previously set order and then use Group Policy ("Computer Configuration" \ "Administrative Templates" \ "Network" \ "SSL Configuration Settings") to configure Cipher Suites via local policy.

The reason of the error "protocol or cipher suite mismatch" can be one from below:

• your server support some "bad cipher suite"
• your server don't support some cipher suite, which MUST be supported corresponds to TLS specification.
• your server supports HTTP/2 and it has some protocols from the the black list above the other protocols, which are not in the list. It's typically enough the change the order of the cipher suites to fix the problem.

The exact black list could be different on different systems. You can find in Internet some blacklist. For example, Appendix A of RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP/2)) contains one list. The cipher suites are TLS_RSA_WITH_AES_128_CBC_SHA for TLS 1.2 (see here) and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.3 (see here). The TLS_ECDHE_ECDSA_* are important only is you use certificate with elliptic curves. Other very good cipher suite TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is not yet implemented by Microsoft. Additionally you can consider to add at least TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA to support connection from old systems and TLS_RSA_WITH_AES_128_CBC_SHA to support very old systems (Android 2.3.7, , Java 6u45, OpenSSL 0.9.8y) and TLS_RSA_WITH_3DES_EDE_CBC_SHA only if you need support IE 8 / XP. Thus you can use today, for example

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

with disabled TLS 1.0, TLS 1.1 to have better security or just

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

if you need to have good security and the best performance.

You can set the following short set of cipher suite for example to solve your problem:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Below I includes an example of configuration on Windows 10. I configured IIS 10 to have A+ rating from Qualys SSL Labs with RSA 2048 key and free SSL certificate from Let's Encrypt.

I disabled DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, Triple DES 168/168, NULL, MD5, Multi-Protocol Unified Hello, PCT 1.0, SSL 2.0, SSL 3.0 and TLS 1.0/1.1 manually in the registry (see KB245030). I disabled TLS 1.0 and TLS 1.1 protocols only because TLS_FALLBACK_SCSV (Downgrade attack) can't be prevented in IIS till now, which makes impossible to get A+ rating of www.ssllabs.com. I see it as an disadvantage, but TLS 1.2 is supported currently very wide. By the way you can use DisabledByDefault: 1, but Enabled: 1 for TLS 1.0 and TLS 1.1. It could be helpful if you would run SQL Server 2008/2012 on the computer. The web server will not use TLS 1.0 and TLS 1.1, but SQL Server do use.

The most important step, which get many my time and which is your main problem was configuration of the the Cipher Suites. I made it using gpedit.msc. I chosen "Computer Configuration" \ "Administrative Templates" \ "Network" \ "SSL Configuration Settings" and configured "SSL Cipher Suite Order" value to the following

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

The above order could be not optimal and I'm not sure, that all above protocols are supported on IIS 7.5 (I used IIS 10.0 from Windows 10). Nevertheless I'm sure that your problem is related with the list of the Cipher Suite, because I had exactly the same problem like you described during my experiments with the list of Cipher Suite.

In any way, after configure the above settings in Group Polity and rebooting the computer (gpupdate /force /target:computer was not enough in my tests) I get A+ ratings and the following list of testing results of the "Handshake Simulation" part:

One can see that iOS is successfuly supported for the following clients:

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

The clients which don't supports TLS 1.2 seems for me now not so important and I think that the above configuration is a good compromise between the support of legacy clients and the usage of safe protocols.

Answer 2

If your IIS Crypto image is recent keep the settings as they are but enable SHA, Diffie-Hellman, and PKCS. This will get you the A rating but allow iOS 8 and lower to connect.

Answer 3

I struggled with this for a few days. In particular I was connecting from an iOS app using Xamarin Forms PCL to connect to a ASP.NET Web Api 2 rest service with OAuth2 Bearer Token authentication.

What worked for me in the end was to use IIS Crypto's Best practices. Then edit the registry key which it set for the cipher suite order:

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

I had success with the following value:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,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_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,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,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The last one was found by using Charles Proxy, which negotiated TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 automatically. The thing that lead me to this was that the connections were succeeding with Charles Proxy on (with simulator certificates installed), but failed otherwise. Adding the suite it used in the negotiation did the trick. It appears(?) that the proxy was renegotiating with my rest service with something that was supported by my server, but not the iOS client.

Note many of the cipher suites were obtained from ssllabs's specification of preferred suites for various iOS/OSX devices. The value above should handshake with everything but IE 6 on XP according to ssllabs, with an A rating.