SSL - 在iOS7中表现不同？ [英] SSL - behaves differently in iOS7?

问题描述

我正在使用iOS企业POS应用程序，该应用程序使用https与服务器通信。我看了接收iOS7 GM中的SSL错误 - AddTrust External CA Root不信任？和自签名之间的区别CA和自签名证书并且通常在网上搜索，但我没有到达任何地方。

I'm working on an iOS Enterprise POS app that communicates with a server using https. I've looked at Receiving SSL error in iOS7 GM - "AddTrust External CA Root" is not trusted? and Difference between self-signed CA and self-signed certificate and generally scoured the web but I'm not getting anywhere.

该应用程序在iOS6.1上使用http或者https协议。它也适用于iOS 7GM over http，但不适用于https - 它在发送给服务器的第一条消息上失败。在应用程序端，我处理身份验证挑战：

The app works fine on iOS6.1 using either http or https protocols. It also works fine on iOS 7GM over http, but not over https - it fails on the first message it sends to the server. On the app side I handle the authentication challenge in:

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

之后我收到回调：

- (void)connectionDidFinishLoading:(NSURLConnection *)connection

NOT：

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

我认为这意味着客户端和服务器成功协商了连接，同意加密协议等。不幸的是，尽管返回似乎成功（就网络堆栈而言），我在AMF有效负载中找回0字节的数据。

I believe that means the client and server successfully negotiated a connection, agreed upon an encryption protocol, etc. Unfortunately although the return appears successful (as far as the network stack is concerned), I get back 0 bytes of data in the AMF payload.

这是有趣的部分 - 在服务器端（JBoss4.2.3）我可以断点并检查包含AMFRequest的httpRequest主体。通过http我总是得到384字节的身体。通过https，如果客户端是iOS 6.1，我得到384字节，如果客户端是iOS 7，我得到0字节。我解释为https请求被服务器正常接受，没有错误，安全违规等等。

Here's the interesting part - on the server side (JBoss4.2.3) I can breakpoint and examine the httpRequest body containing the AMFRequest. Over http I always get 384 bytes in the body. Over https, I get 384 bytes if the client is iOS 6.1, but 0 bytes if the client is iOS 7. I interpret that as the https request was accepted "normally" by the server with no errors, security violations, etc.

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

One more data point. If I run Charles on the client side everything works correctly over https using the iOS 7 simulator. I can see my 384 byte AMFRequest just fine in both Charles and on the server. Charles works as an http proxy - but the app doesn't know anything about that, so why does inserting Charles as an intermediary make it work? I've installed Charles' certificate so I think it is communicating to the server over SSL (don't know for sure).

感谢您提供任何帮助或建议。

Thanks for any help or suggestions.

更新：我实施了Apple推荐的方法：

Update: I implemented Apple's recommended approach:

- (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之前版）完全相同。

but it gets exactly the same result as the old (pre iOS 5) way.

推荐答案

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

After considerable research I opened a incident with Apple Developer Tech Support and eventually have an explanation.

我已经确认苹果公司在iOS 7中做了一个BEAST攻击的推荐对策，这是针对SSL TLS协议的中间人攻击 - 请参阅此有关CERT的文章。

I've been able to confirm that Apple made a change in iOS 7 as a "recommended countermeasure to the BEAST attack", which is a "man in the middle" attack against the SSL TLS protocol - see this article on CERT.

理想的解决方案是更改要使用的JBoss（Tomcat）ssl连接器：

The ideal solution would be to change the JBoss (Tomcat) ssl connector to use:

sslProtocol="TLSv1.2"

不幸的是，JBoss4.2.3GA实施的股票无法处理TLSv1.1或TLSv1。 2，或处理使用此对策的消息。似乎唯一的解决方案是升级JBoss配置。这需要进行重大的JBoss更改 - 请参阅此 JBoss文章。

Unfortunately the stock JBoss4.2.3GA implementation is unable to handle TLSv1.1 or TLSv1.2, or process messages that use this countermeasure. It appears the only solution is to upgrade the JBoss configuration. That requires significant JBoss changes - see this JBoss article.

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

An alternative is to re-write the networking methods to use a lower level framework (CFSocketStream instead of NSURLConnection) and disable the BEAST countermeasure. That has two downsides - it re-exposes the security vulnerability and it is a non-trivial implementation that would need thorough testing (especially simulating network edge cases).

在我的案件时间不允许在假日季节之前改变这种程度。我的客户是一家大型零售商，他们的IT部门在10月中旬锁定了环境。

In my case time does not permit changes of such magnitude prior the Holiday season. My client is a major retailer and their IT department locks down the environment in mid-October.

也许这些信息可以帮助其他人。

Perhaps this information will help someone else.

这篇关于SSL - 在iOS7中表现不同？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！