ios - SSL - 在 iOS7 中表现不同？

Question

我正在开发一个使用 https 与服务器通信的 iOS Enterprise POS 应用程序。我看过 Receiving SSL error in iOS7 GM - "AddTrust External CA Root" is not trusted?和 Difference between self-signed CA and self-signed certificate并且通常在网络上进行搜索，但我一无所获。

该应用程序在 iOS6.1 上运行良好，使用 http 或 https 协议(protocol)。它也可以通过 http 在 iOS 7GM 上正常工作，但不能通过 https - 它在发送到服务器的第一条消息时失败。在应用端，我通过以下方式处理身份验证挑战:

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge: (NSURLAuthenticationChallenge *)challenge 
{
    [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] 
         forAuthenticationChallenge:challenge];
}

之后我收到回调:

- (void)connectionDidFinishLoading:(NSURLConnection *)connection

不是:

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error

我相信这意味着客户端和服务器成功地协商了一个连接，同意了一个加密协议(protocol)等。不幸的是，虽然返回看起来成功(就网络堆栈而言)，但我在AMF 负载。

这是有趣的部分 - 在服务器端 (JBoss4.2.3) 我可以断点并检查包含 AMFRequest 的 httpRequest 主体。在 http 上，我总是在正文中得到 384 个字节。通过 https，如果客户端是 iOS 6.1，我得到 384 个字节，但如果客户端是 iOS 7，我得到 0 个字节。我将其解释为服务器“正常”接受了 https 请求，没有错误、安全违规等。

还有一个数据点。如果我在客户端运行 Charles，一切都可以使用 iOS 7 模拟器在 https 上正常运行。我可以在 Charles 和服务器上看到我的 384 字节 AMFRequest。 Charles 用作 http 代理 - 但应用程序对此一无所知，那么为什么插入 Charles 作为中介使其起作用？我已经安装了 Charles 的证书，所以我认为它正在通过 SSL 与服务器通信(不确定)。

感谢任何帮助或建议。

更新:我实现了 Apple 推荐的方法:

- (void)connection: (NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
{
    traceMethod();
    SecTrustRef trust = challenge.protectionSpace.serverTrust;
    NSURLCredential *credential = [NSURLCredential credentialForTrust: trust];
    [challenge.sender useCredential: credential
         forAuthenticationChallenge: challenge];
}

但它得到的结果与旧的(iOS 5 之前的)方式完全相同。

Answer 1

经过大量研究后，我向 Apple Developer Tech Support 发起了一个事件，并最终得到了解释。

我已经能够确认 Apple 在 iOS 7 中进行了更改，作为“针对 BEAST 攻击的推荐对策”，这是针对 SSL TLS 协议(protocol)的“中间人”攻击 - 参见 article on CERT .

理想的解决方案是将 JBoss (Tomcat) ssl 连接器更改为使用:

sslProtocol="TLSv1.2"

不幸的是，现有的 JBoss4.2.3GA 实现无法处理 TLSv1.1 或 TLSv1.2，也无法处理使用此对策的消息。看来唯一的解决办法是升级 JBoss 配置。这需要对 JBoss 进行重大更改 - 请参阅此 JBoss article .

另一种方法是重写网络方法以使用较低级别的框架(CFSocketStream 而不是 NSURLConnection)并禁用 BEAST 对策。这有两个缺点 - 它重新暴露了安全漏洞，并且它是一个需要彻底测试(尤其是模拟网络边缘情况)的重要实现。

就我而言，时间不允许在假期之前发生如此大的变化。我的客户是一家大型零售商，他们的 IT 部门在 10 月中旬锁定了环境。

也许这些信息会对其他人有所帮助。