SSL – 在iOS7中performance有所不同？

我正在研究使用https与服务器通信的iOS企业POS应用程序。 我已经看过在iOS7通用接收SSL错误 – “AddTrust外部CA根”不信任？ 和自签名的CA和自签名证书之间的区别 ，一般在网上search，但我没有得到任何地方。

该应用程序使用http或https协议在iOS6.1上正常工作。 它也可以通过HTTP在iOS 7GM上正常工作，但不能通过https – 在发送给服务器的第一条消息时失败。 在应用程序方面，我处理身份validation挑战： 

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

之后我得到一个callback： 

 - (void)connectionDidFinishLoading:(NSURLConnection *)connection

不： 

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

我相信这意味着客户端和服务器成功地协商了一个连接，同意一个encryption协议等。不幸的是，虽然返回看起来是成功的（就networking堆栈而言），但是我在AMF有效载荷中取回了0字节的数据。

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

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

感谢您的任何帮助或build议。

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

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

经过相当多的研究后，我与苹果开发者技术支持公司开了一个事件，最终得到了解释

我已经能够确认苹果公司在iOS 7中作了一个“对BEAST攻击的推荐对策”，这是一个“中间人”针对SSL TLS协议的攻击 – 请参阅关于CERT的这篇文章 。

理想的解决scheme是更改JBoss（Tomcat）ssl连接器来使用： 

 sslProtocol="TLSv1.2"

不幸的是，现有的JBoss4.2.3GA实现无法处理TLSv1.1或TLSv1.2，或者处理使用这种对策的消息。 看来唯一的解决办法是升级JBossconfiguration。 这需要重大的JBoss变化 – 请参阅这篇JBoss文章 。

另一种方法是重新编写联网方法以使用较低级别的框架（CFSocketStream而不是NSURLConnection）并禁用BEAST对策。 这有两个缺点 – 它重新暴露了安全漏洞，这是一个不平凡的实现，需要彻底的testing（特别是模拟networking边缘案例）。

在我的情况下，时间不允许在假日季节之前如此大小的变化。 我的客户是一家大型零售商，他们的IT部门在十月中旬locking了环境。

也许这个信息会帮助别人。

API中的SSL肯定发生了变化

我不太了解SSL是如何工作的，但是我注意到MKNetworkKit正在使用一个现在已经被弃用的iOS 7常量，叫做kSecTrustResultConfirm （在Security-Framework的SecTrust.h中）：

@constant kSecTrustResultConfirm在继续之前指示需要用户确认。 重要提示：此值不再由SecTrustEvaluate或从OS X 10.5开始的SecTrustSettings API返回或支持; 在OS X 10.9及更高版本以及iOS中不推荐使用它。

也许这是一个正确的方向？ 无论如何，祝你好运解决您的问题！

这是在MKNetworkKit中“固定”这个提交差异： https : //github.com/MugunthKumar/MKNetworkKit/commit/c28959805991bb8f0e99ede9c822e985b41f6fc9 （向下滚动到L：1142）

有同样的问题得到iOS 7与Jboss eap 6.0.1 resteasy方法交谈。

答案是将ssl标签协议设置为TLSv1.2。 例如 

 <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="ssl" key-alias="awssink" password="keystore-password" certificate-key-file="${jboss.server.config.dir}/attimoto.jks" verify-client="false" protocol="TLSv1.2"/> </connector>

现在我们使用承载令牌访问宁静的方法，所以使用AFNetworking 2+我们做这样的事情： 

 NSString *secureURLString = [secureBaseURLString stringByAppendingString:BURP]; NSLog(@"the secure url is %@\n\n", secureURLString); // set up the request manager AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; // allow invalid certificates manager.securityPolicy.allowInvalidCertificates = YES; //Note we dont deal with pinned certificates since we are doing bearer token manager.responseSerializer = [AFHTTPResponseSerializer serializer]; manager.requestSerializer = [AFHTTPRequestSerializer serializer]; [manager.requestSerializer setValue:BEARER_TOKEN forHTTPHeaderField:@"Authorization"]; //Note we do NOT use setAuthorizationHeaderFieldWithToken:BEARER_TOKEN]; //Ultimately you want just a header like this // "Authorization: Bearer textofthebearertoken" //So BEARER_TOKEN is literally @"Bearer thetextofthebearertoken" [manager GET:secureURLString parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) { NSLog(@" RESPONSE RETURNED %@\n\n", responseObject); } failure:^(AFHTTPRequestOperation *operation, NSError *error) { NSLog(@"error = %@", error); }];

在NSURLConnection和Amazons ELB＆EC2实例中，ELB没有启用TLS v1.2，导致15-50％的请求没有得到正确处理（HTTPS PUT与身体内的JSON）有问题。 打开TLS v1.2解决了这个问题…抓住我的头，试图找出这个事实背后的逻辑。

Interesting Posts