SSL - 在iOS7中表現有所不同？

我正在使用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，並且通常搜索網頁，但我沒有找到任何地方。SSL - 在iOS7中表現有所不同？

該應用在iOS6.1上使用http或https協議工作正常。它也可以通過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

NOT：

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

我相信，這意味着客戶機和服務器成功協商連接，同意加密協議等。不幸的是，儘管返回看起來成功（就網絡堆棧而言），但我在AMF pa中返回了0字節的數據yload。

這裏有一個有趣的現象 - 在服務器端（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與服務器通信的（不知道肯定）。

感謝您的任何幫助或建議。

更新：我實現了蘋果公司推薦的方法：

- (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中）的方式。

來源

2013-09-26 Kevin OMara

相當多的研究，我打開與蘋果開發者技術支持一個事件，最終有後說明。

我已經能夠確認Apple在iOS 7中對「BEAST攻擊的推薦對策」進行了更改，這是針對SSL TLS協議的「中間人」攻擊 - 請參閱此article on CERT。

理想的解決辦法是改變了JBoss（Tomcat）的SSL連接器的使用方法：

sslProtocol="TLSv1.2"

不幸的是，股票JBoss4.2.3GA實現無法處理TLSv1.1或TLSv1.2工作，或者進程使用這種對策的消息。看來唯一的解決方案是升級JBoss配置。這需要大量的JBoss更改 - 請參閱此JBoss article。

另一種方法是重寫聯網方法以使用較低級別的框架（CFSocketStream而不是NSURLConnection）並禁用BEAST對策。這有兩個缺點 - 它重新暴露了安全漏洞，這是一個不平凡的實施，需要進行全面的測試（特別是模擬網絡邊緣案例）。

在我的情況下，時間不允許在假日季節之前變化這麼大。我的客戶是一家大型零售商，他們的IT部門在十月中旬鎖定了環境。

也許這些信息會幫助別人。

來源

2013-10-04 17:30:47

已經有肯定是要改變的SSL API

我不知道很多關於SSL是如何工作的，但我注意到，MKNetworkKit使用現在已經過時，在iOS中7稱爲恆kSecTrustResultConfirm（中發現的安全框架中的SecTrust.h）：

@constant kSecTrustResultConfirm指示在繼續之前需要用戶的確認。重要提示：此值不再返回或由SecTrustEvaluate或SecTrustSettings API支持，起始於 OS X 10.5;它的使用在OS X 10.9及更高版本以及iOS中不推薦使用。

也許這是一個正確的方向？無論如何，祝你好運解決您的問題！

這是提交DIFF其中有人「固定」這MKNetworkKit： https://github.com/MugunthKumar/MKNetworkKit/commit/c28959805991bb8f0e99ede9c822e985b41f6fc9 （向下滾動到L：1142）

來源

2013-09-26 19:32:14 Wirsing

感謝您的信息。我不認爲就是這樣。在我們的情況下，我們只需要一個加密流（以符合cc安全標準），所以我們總是回覆「serverTrust」。 –

歡迎你，值得一試;）祝你好運！ – Wirsing

有這個相同的問題得到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); 
    }];

來源

2013-12-03 16:11:11 crussell42

曾與NSURLConnection的和亞馬遜ELB & EC2實例的問題，其中ELB沒有啓用TLS v1.2，導致15-50％的請求沒有得到正確處理（HTTPS PUT與正文中的JSON）。打開TLS v1.2解決了這個問題...抓住我的頭試圖找出這個事實背後的邏輯。

來源

2014-02-16 22:11:50

SSL - 在iOS7中表現有所不同？

回答

相關問題