如何配置IIS 7.5 SSL \ TLS以与iOS 9 ATS一起使用

问题：由于iOS 9现在使用ATS，因此我们的移动应用程序无法再与我们的Web服务建立安全连接。

背景： iOS 9引入了App Transport Security

服务器设置： Windows Server 2008 R2 SP1（VM）IIS 7.5，来自digicert的SSL证书。Windows防火墙关闭。

密钥RSA 2048位（e 65537）

发行者DigiCert SHA2安全服务器CA

签名算法SHA512withRSA

这些是应用程序传输安全性要求：

服务器必须至少支持传输层安全性（TLS）协议版本1.2。连接密码仅限于提供前向保密性的密码（请参阅下面的密码列表。）证书必须使用SHA256或更好的签名哈希算法进行签名，并使用2048位或更高的RSA密钥或256位或更高的Elliptic-Curve （ECC）键。无效的证书会导致严重故障并且无法连接。这些是公认的密码：

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

已经尝试了什么：

1. 在移动应用程序中添加例外以允许我们的域工作，但是我不想使用这种不安全的方法，我想修复我们的SSL。
2. 使用IIS Crypto来使用“最佳实践”，尝试过“ pci”和自定义设置。甚至尝试将加密套件修改为上面的列表，然后重新排序。每次尝试后，服务器将重新启动，并且SSL Labs已运行（清除缓存后）。我成功地从F等级升级到A甚至A-，但这仅导致iOS 8和9无法建立安全连接。（NSURLErrorDomain代码= -1200和_kCFStreamErrorCodeKey = -9806）
3. 恢复了VM，并尝试了Powershell脚本为SSL完美的IIS和TLS 1.2设置了IIS我什至进行了第二次尝试，在该过程中，我将Power脚本中的密码加密为所需内容的最小清单。

结果：始终相似，等级为A或A-。iOS8和iOS9无法协商安全连接。握手模拟会导致Safari和iOS产品出现“协议或密码套件不匹配”的情况。

更新在获得Apple支持之后，我们进行了一些数据包跟踪捕获：

$ 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

前三个数据包是建立TCP连接的经典SYN-SYN-ACK-ACK三向握手。第四个数据包是iOS向您的服务器发送TLS客户端问候消息，这是在该TCP连接上建立TLS连接的第一步。我把这个信息拆开了，看起来很合理。服务器在第五个数据包中简单地丢弃连接（通过发送RST）。

有谁知道为什么IIS 7.5会执行RST？

这个问题很旧，但是会在搜索过程中找到。我花了一些时间来找到解决同一问题的方法。因此，我决定写答案以与他人分享我的结果。

简短的答案：您不应使用IIS Crypto来指定密码套件的顺序。我建议您单击“默认”按钮以删除先前设置的顺序，然后使用组策略（“计算机配置” \“管理模板” \“网络” \“ SSL配置设置”）通过本地策略配置密码套件。

错误“协议或密码套件不匹配”的原因可能是以下原因之一：

• 您的服务器支持某些“错误密码套件”
• 您的服务器不支持某些密码套件，必须与TLS规范相对应。
• 您的服务器支持HTTP / 2，并且其黑名单中的 某些协议位于其他协议之上，而这些协议不在列表中。通常，更改密码套件的顺序就足以解决问题。

确切的黑名单在不同的系统上可能有所不同。您可以在Internet中找到一些黑名单。例如，RFC 7540（超文本传输​​协议版本2（HTTP / 2））的附录A包含一个列表。该密码套件TLS_RSA_WITH_AES_128_CBC_SHA的TLS 1.2（见这里），并TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256和TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256使用TLS 1.3（见这里）。将TLS_ECDHE_ECDSA_*是重要的不仅是您使用证书与椭圆曲线。TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256Microsoft尚未实现其他非常好的密码套件。另外，仅在需要支持IE 8 / XP时，您才可以考虑添加至少TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA支持旧系统的连接并TLS_RSA_WITH_AES_128_CBC_SHA支持非常旧的系统（Android 2.3.7，Java 6u45，OpenSSL 0.9.8y）TLS_RSA_WITH_3DES_EDE_CBC_SHA。例如，您今天可以使用

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

禁用TLS 1.0和TLS 1.1可以提高安全性，或者

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

如果您需要良好的安全性和最佳性能。

您可以设置以下简短的密码套件集来解决您的问题：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

下面，我提供了Windows 10上的配置示例。我将IIS 10配置为具有Qualys SSL Labs的A +等级，并具有RSA 2048密钥和来自Let's Encrypt的免费SSL证书。

我禁用了DES 56/56，RC2 128/128，RC2 40/128，RC2 56/128，RC4 128/128，RC4 40/128，RC4 56/128，RC4 64/128，三重DES 168/168，NULL， MD5，多协议统一Hello，PCT 1.0，SSL 2.0，SSL 3.0和TLS 1.0 / 1.1 在注册表中手动进行（请参阅KB245030）。我之所以禁用TLS 1.0和TLS 1.1协议，仅是因为到目前为止，IIS中仍无法阻止TLS_FALLBACK_SCSV（降级攻击），这使得无法获得www.ssllabs.com的 A +评级。我认为这是一个缺点，但是目前支持TLS 1.2的范围非常广泛。顺便说一下，您可以使用DisabledByDefault: 1，但Enabled: 1适用于TLS 1.0和TLS 1.1。如果您要在计算机上运行SQL Server 2008/2012，这可能会有所帮助。Web服务器将不使用TLS 1.0和TLS 1.1，但是SQL Server会使用。

最重要的一步，这让我花了很多时间，而这是您的主要问题是密码套件的配置。我使用制作gpedit.msc。我选择了“计算机配置” \“管理模板” \“网络” \“ SSL配置设置”，并将“ SSL密码套件顺序”的值配置为以下值

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

上面的顺序可能不是最优的，并且我不确定IIS 7.5（我使用Windows 10的IIS 10.0）是否支持上述所有协议。不过，我确定您的问题与密码套件的列表有关，因为我遇到的问题与您在使用密码套件的列表进行实验时所描述的完全相同。

无论如何，在Group Polity中配置上述设置并重新启动计算机之后（gpupdate /force /target:computer在我的测试中还不够），我获得了A +等级以及“握手模拟”部分的以下测试结果列表：

可以看到以下客户端成功支持iOS：

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

对于我来说，不支持TLS 1.2的客户端现在似乎并不那么重要，并且我认为上述配置是对旧客户端的支持和安全协议的使用之间的良好折衷。

如果您的IIS加密映像是最新的，则保持设置不变，但是启用SHA，Diffie-Hellman和PKCS。这将使您获得A级，但允许iOS 8及更低版本进行连接。

我为此挣扎了几天。特别是，我使用Xamarin Forms PCL从iOS应用程序进行连接，以通过OAuth2 Bearer Token身份验证连接到ASP.NET Web Api 2 rest服务。

最后对我有用的是使用IIS Crypto的最佳实践。然后编辑它为密码套件顺序设置的注册表项：

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

我成功实现了以下价值：

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

使用Charles Proxy找到了最后一个，该代理自动协商了TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。导致我这样做的原因是，在Charles Proxy启用（安装了模拟器证书）的情况下，连接已成功，但在其他情况下失败。添加它在协商中使用的套件就可以了。似乎（？）代理正在通过我的服务器（而不是iOS客户端）支持的功能与我的REST服务重新协商。

请注意，许多密码套件是从ssllabs针对各种iOS / OSX设备的首选套件规范中获得的。 根据ssllabs，以上值应与XP上的IE 6以外的所有内容进行握手，且等级为A。