Question

我正在开发一个使用https与服务器通信的iOS企业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协议正常工作。它也适用于iOS 7GM over http，但不能通过https - 它在发送到服务器的第一条消息上失败。在应用程序端，我处理身份验证挑战：

- (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

我认为这意味着客户端和服务器成功协商了连接，同意了加密协议等。不幸的是，虽然返回看起来成功（就网络堆栈而言），我回到了0字节的数据AMF有效载荷。

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

还有一个数据点。如果我在客户端运行 Charles ，则使用iOS 7模拟器在https上正常运行。我可以在Charles和服务器上看到我的384字节AMFRequest。查尔斯作为一个http代理工作 - 但该应用程序对此一无所知，那么为什么插入查尔斯作为中介使其工作？我已经安装了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协议的“中间人”攻击 - 请参阅{{3 }}

理想的解决方案是将JBoss（Tomcat）ssl连接器更改为：

sslProtocol="TLSv1.2"

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

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

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

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

Answer 2

API中的SSL确实发生了变化

我不太了解SSL是如何工作的，但我注意到MKNetworkKit在iOS 7常量中使用了一个名为 kSecTrustResultConfirm 的新功能（在Security-Framework的SecTrust.h中找到）：

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

也许这是朝着正确方向发展的一点？无论如何，祝你好运解决问题！

这是提交差异，其中有人在MKNetworkKit中“修复”了这个： https://github.com/MugunthKumar/MKNetworkKit/commit/c28959805991bb8f0e99ede9c822e985b41f6fc9 （向下滚动到L：1142）

Answer 3

同样的问题让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>

现在我们使用Bearer令牌来访问restful方法，所以使用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);
     }];

Answer 4

NSURLConnection和Amazons ELB＆amp; EC2实例，其中ELB没有启用TLS v1.2，导致15-50％的请求未正确处理（身份中带有JSON的HTTPS PUT）。转向TLS v1.2解决了这个问题......抓住我的脑袋试图找出这个事实背后的逻辑。

SSL - 在iOS7中表现不同？

4 个答案: