iOS 8.4 CFNetwork SSLHandshake 失败 (-9850)
iOS 8.4 CFNetwork SSLHandshake failed (-9850)
我的 ssl 握手代码失败，因为我将 xcode 更新为 6.4（并将模拟器更新为 ios 8.4）。
错误是：CFNetwork SSLHandshake 失败（-9850）
同样的代码在 ios 8.3 模拟器上成功地执行了 ssl 握手（我也尝试了 ios 8.3 模拟器从 xcode 6.4 并且握手很好）。
这是配置并启动握手的代码段。我正在使用 swift.
self.socket.startTLS([kCFStreamSSLLevel:kCFStreamSocketSecurityLevelTLSv1,
kCFStreamSSLValidatesCertificateChain:kCFBooleanFalse])
我整天都在试图弄清楚这个问题，但我什至无法找出错误代码 -9850 的含义。它没有与 SecureTransport.h 文件中的所有其他代码一起列出。
更新1：
我发现苹果引入了应用程序传输安全性，这意味着您可以声明要建立安全连接的域。无论如何，我尝试使用 ATS 但没有成功。 -9850 错误仍在制造问题。
更新 2 - 解决方案
正如 Michal 和 Steven 在他们的回答中所建议的那样，我开始怀疑主要问题出在服务器端，这最终是真的。
我与实施服务器的人交谈，在他生成长度为 2048 的新 ssl 证书后，所有问题都消失了。在此之前，它们是 512。
使用新证书，我这边的代码工作得很好。
当我收到 CFNetwork SSLHandshake failed -(*) 这是因为我的设备已连接到网络但未连接到互联网。
我认为这与coreTLS有关：
Description: coreTLS accepted short ephemeral Diffie-Hellman (DH) keys, as used in export-strength ephemeral DH cipher suites. This issue, also known as Logjam, allowed an attacker with a privileged network position to downgrade security to 512-bit DH if the server supported an export-strength ephemeral DH cipher suite. The issue was addressed by increasing the default minimum size allowed for DH ephemeral keys to 768 bits.
从你的代码中我可以看出，我猜你正在使用 GCDAsyncSocket。 10个月前更新过，肯定反映不了这个问题
-9850 出现在SecureTransport.h header 埋在iOS 9 SDK:
errSSLWeakPeerEphemeralDHKey = -9850, /* weak ephemeral dh key */
听起来 Michal 的方向是对的。对这个问题的更一般的搜索让我找到了 http://www.chromium.org/administrators/err_ssl_weak_server_ephemeral_dh_key:
As of Chrome 45, this error message is triggered if the SSL/TLS handshake attempts to use a public key, smaller than 1024 bits, for ephemeral Diffie-Hellman key agreement.
我并不是说 iOS 9 强加了与 Chrome 完全相同的要求，但我会开始查看服务器配置以及是否可以增加它用于的密钥大小SSL 握手。
我的 ssl 握手代码失败，因为我将 xcode 更新为 6.4（并将模拟器更新为 ios 8.4）。
错误是：CFNetwork SSLHandshake 失败（-9850）
同样的代码在 ios 8.3 模拟器上成功地执行了 ssl 握手（我也尝试了 ios 8.3 模拟器从 xcode 6.4 并且握手很好）。
这是配置并启动握手的代码段。我正在使用 swift.
self.socket.startTLS([kCFStreamSSLLevel:kCFStreamSocketSecurityLevelTLSv1,
kCFStreamSSLValidatesCertificateChain:kCFBooleanFalse])
我整天都在试图弄清楚这个问题，但我什至无法找出错误代码 -9850 的含义。它没有与 SecureTransport.h 文件中的所有其他代码一起列出。
更新1：
我发现苹果引入了应用程序传输安全性，这意味着您可以声明要建立安全连接的域。无论如何，我尝试使用 ATS 但没有成功。 -9850 错误仍在制造问题。
更新 2 - 解决方案
正如 Michal 和 Steven 在他们的回答中所建议的那样，我开始怀疑主要问题出在服务器端，这最终是真的。
我与实施服务器的人交谈，在他生成长度为 2048 的新 ssl 证书后，所有问题都消失了。在此之前，它们是 512。
使用新证书，我这边的代码工作得很好。
当我收到 CFNetwork SSLHandshake failed -(*) 这是因为我的设备已连接到网络但未连接到互联网。
我认为这与coreTLS有关：
Description: coreTLS accepted short ephemeral Diffie-Hellman (DH) keys, as used in export-strength ephemeral DH cipher suites. This issue, also known as Logjam, allowed an attacker with a privileged network position to downgrade security to 512-bit DH if the server supported an export-strength ephemeral DH cipher suite. The issue was addressed by increasing the default minimum size allowed for DH ephemeral keys to 768 bits.
从你的代码中我可以看出，我猜你正在使用 GCDAsyncSocket。 10个月前更新过，肯定反映不了这个问题
-9850 出现在SecureTransport.h header 埋在iOS 9 SDK:
errSSLWeakPeerEphemeralDHKey = -9850, /* weak ephemeral dh key */
听起来 Michal 的方向是对的。对这个问题的更一般的搜索让我找到了 http://www.chromium.org/administrators/err_ssl_weak_server_ephemeral_dh_key:
As of Chrome 45, this error message is triggered if the SSL/TLS handshake attempts to use a public key, smaller than 1024 bits, for ephemeral Diffie-Hellman key agreement.
我并不是说 iOS 9 强加了与 Chrome 完全相同的要求，但我会开始查看服务器配置以及是否可以增加它用于的密钥大小SSL 握手。