jbl*_*ack 18 iphone ssl objective-c nsurlconnection ios
是否可以销毁使用NSURLConnection创建的持久连接?我需要能够销毁持久连接并进行另一次SSL握手.
就像现在一样,调用[conn cancel]后面会留下一个持久连接,用于与该主机的下一个连接请求,我不想发生这种情况.
jbl*_*ack 18
事实证明,我认为安全传输TLS会话缓存是罪魁祸首.
我还在苹果开发者论坛上提出了这个问题,并得到了苹果公司的回复.他向我指出了这个Apple示例代码自述文件,其中说:
在iOS和Mac OS X的TLS堆栈底部是一个称为安全传输的组件.Secure Transport维护每进程TLS会话缓存.通过TLS连接时,缓存存储有关TLS协商的信息,以便后续连接可以更快地连接.在线链接机制在下面的链接中描述.
http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake
这提出了一些有趣的问题,特别是在您进行调试时.例如,请考虑以下顺序:
使用"调试"选项卡将"TLS服务器验证"设置为"已禁用".
您连接到具有自签名身份的站点.连接成功,因为您已禁用TLS服务器信任验证.这会向Secure Transport TLS会话缓存添加一个条目.
您可以使用"调试"选项卡将TLS服务器验证设置为"默认".
您可以立即连接到与步骤2中相同的站点.由于服务器信任验证策略的更改,这应该会失败,但它会成功,因为您从未收到过NSURLAuthenticationMethodServerTrust质询.在幕后,Secure Transport已经恢复了TLS会话,这意味着挑战永远不会达到您的水平.
另一方面,如果你在第3步和第4步之间延迟了11分钟,事情按预期工作(好吧,按预期失败:-).这是因为Secure Transport的TLS会话缓存超时为10分钟.
在现实世界中,这不是一个大问题,但在调试过程中可能会非常混乱.清除安全传输TLS会话缓存没有编程方法,但由于缓存是按进程进行的,因此您可以通过简单地退出并重新启动应用程序来避免调试期间出现此问题.请记住,从iOS 4开始,按"主页"按钮不一定会退出您的应用程序.相反,您应该使用退出最近的应用程序列表中的应用程序.
因此,基于此,用户必须要么杀死他们的应用程序并重新启动它,要么等待超过10分钟才能发送另一个请求.
我使用这些新信息进行了另一次谷歌搜索,并发现这篇Apple技术问答文章完全符合这个问题.在底部附近,它提到添加尾随'.' 为了强制TLS会话缓存未命中(如果你不能以某种方式修改服务器,我不能),请求域名(并希望IP地址),所以我将尝试这个,希望它将工作.我会在测试后发布我的发现.
### EDIT ###
我测试了添加'.' 到IP地址的末尾,请求仍然成功完成.
但我一般都在考虑这个问题,并且没有理由强制进行另一次SSL握手.就我而言,此问题的解决方案是保留从服务器返回的最后一个已知SecCertificateRef的副本.当向服务器发出另一个请求时,如果使用了缓存的TLS会话(connection:didReceiveAuthenticationChallenge:
未被调用),我们知道保存SecCertificateRef
的仍然有效.如果connection:didReceiveAuthenticationChallenge:
被调用,我们可以SecCertificateRef
在那时获得新的.
归档时间: |
|
查看次数: |
3365 次 |
最近记录: |