CFNetwork SSLHandshake间歇性地失败（-9806）

Question

我正在使用iOS应用程序，在iOS 9中进行测试时出现以下错误。

CFNetwork SSLHandshake failed (-9806)    
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9806)    

我发现有很多链接说这可能是由于NSAppTransportSecurity建议为我的域添加例外或禁用ATS。但我的服务器确实支持TLS1.2，我只是间歇性地得到这个问题。如果这是由于NSTransportSecurity，我认为问题应该是一致的。 奇怪的是，这并不一致。该应用程序工作正常，并在大多数情况下能够连接到服务器。但过了一会儿我得到了上面的错误。我使用NSURLCONNECTION。大多数应用程序交互就像点击按钮一样，它会对服务器（tomcat）进行网络调用。一旦发生SSL失败错误，让应用程序成功向服务器发送请求的唯一方法是杀死应用程序并重新启动。我已经尝试在问题期间将连接从wifi更改为3g，甚至在问题发生后重新启动服务器但我找不到运气。我可以使用safari和其他应用程序正常工作。我一直试图找到一个解决方案。服务器未启用前向保密。

要深入检查问题，我验证了来自客户端的SSL数据包。 出现问题时，与连接正常工作时相比，客户端发送的密码列表不同。

当连接正常时，我可以看到下面的密码列表被发送。

还发现在发布期间客户端hello数据包显示为SSL，当连接良好时，客户端hello数据包显示为TLS1.2

发行期间

没有问题的时候

我使用相同的NSurlconnetion类连接整个应用程序中的服务器。我很困惑为什么以及如何可能存在这样的差异以及一次运行的同一服务器调用如何以后不起作用。以上数据是否表明在发布期间客户端正在尝试通过tls1.0或更低版本进行连接？服务器仅支持TLS 1.1和TLS 1.2。该问题仅在iOS 9中找到。非常感谢任何帮助。

Answer 1

应用程序可能会从TLS 1.2开始，并且将提供TLS 1.2新增的密码（名称中带有GCM的密码）。然后我猜有一些握手问题，可能是由于临时服务器问题，一些中间件（防火墙）介于两者之间。从那时起，应用程序假定TLS 1.2存在问题，并将尝试使用降级连接，即TLS 1.0。并保持这种方式，因为“它知道”TLS 1.2无法正常工作。

这种降级通常也会在浏览器中出现，但通常只有在至少一次成功时才会记得降级。是否会有一些SSL拦截中间件（防火墙）导致原始TLS 1.2失败并降级成功？ I.E.问题是在设备通过此中间件连接一次然后再尝试重新连接到您的站点之后才会发生？