iOS 9 ATS和Firebase REST

我正在構建一個使用REST API與Firebase進行對話的簡單iOS應用程序。iOS 9 ATS和Firebase REST

從本質上講，我使用NSURLSession.sharedSession().dataTaskWithRequest連接到

https://myusername.firebaseio.com/Object.json

該應用程序在iOS版8.正常工作，我能夠通過GET/PUT/PATCH/DELETE操作我的數據。但由於iOS的9中引入的ATS，我現在有HTTPS錯誤：

NSURLSession/NSURLConnection HTTP load failed

(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake failed)

我深知在Info.plist的變通辦法解決的。但是，我想利用iOS 9中的新安全功能。

我檢查了Firebase連接安全性（通過單擊Chrome的綠色鎖定按鈕），並且它似乎與Apple的ATS要求兼容。

是我的錯誤，因爲我使用NSURLSession的方式？或者是因爲Firebase安全設置？

PS：我測試了https://firebase.com和NSURLSession連接沒有錯誤。我的應用程序也很簡單，我不需要授權。

謝謝你的幫助。

來源

2015-07-10 User5103156

很難猜測的iOS是不滿從錯誤。如果您找到了挖掘更多詳細錯誤信息的方法，請發送電子郵件至[email protected]，我們可以看看我們是否可以確定iOS不喜歡我們的SSL配置。 –

謝謝。我將複製錯誤消息和電子郵件支持。 – User5103156

TL; DR：它與Firebase服務器允許的SSL密碼有關（ATS只需要ECDHE即可）。

如前所述，在Info.plist的解決辦法是添加以下內容：

<key>NSAppTransportSecurity</key> 
    <dict> 
     <key>NSExceptionDomains</key> 
     <dict> 
      <key>firebaseio.com</key> 
      <dict> 
       <key>NSIncludesSubdomains</key> 
       <true/> 
       <key>NSThirdPartyExceptionRequiresForwardSecrecy</key> 
       <false/> 
      </dict> 
     </dict> 
    </dict>

在ATS docs，蘋果只允許以下開箱：

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

設置NSThirdPartyExceptionRequiresForwardSecrecy國旗NO Info.plist中增加了以下額外的：

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
TLS_RSA_WITH_AES_256_GCM_SHA384 
TLS_RSA_WITH_AES_128_GCM_SHA256 
TLS_RSA_WITH_AES_256_CBC_SHA256 
TLS_RSA_WITH_AES_256_CBC_SHA 
TLS_RSA_WITH_AES_128_CBC_SHA256 
TLS_RSA_WITH_AES_128_CBC_SHA

我不同意將他們的國旗命名爲「... ExceptionRequiresForwardSecrecy」，因爲技術上DHE提供了完美的前向保密性，只比相應的ECDHE版本慢。聽起來像我應該有兩個標誌，一個是提出保密的例外，一個只是說你很舒服握手較慢。

從技術上講，你也可以使例外域<your-firebase-app>.firebaseio.com，並沒有NSIncludesSubdomains標誌，但我想這樣做足夠通用。

既然我們允許非ECDHE密碼，火力地堡將不得不禁止其服務器端的這開箱工作（除非開發商想先從較低層次的東西比的NSURLRequest亂搞，看到this SO post關於配置的詳細信息SSL密碼，但是你會花費更多的時間來做這件事，而不是增加幾行Info.plist）。安全方面，我們提供相同版本的相同密碼，只是不使用橢圓曲線版本（提供不錯的性能改進，但排除某些瀏覽器[特別是移動瀏覽器]）。有關DHE vs ECDHE的更多信息（以及其他一些不錯的SSL背景w.r.t Forward Secrecy是here）。

對於它的價值，實時客戶端不存在這個問題，所以我會強烈建議使用那些美好火力地堡體驗:)

來源

2015-07-12 06:37:32

感謝您的意見。我切換到了Firebase SDK。只是想提及XCode 7默認情況下將ENABLE_BITCODE設置爲yes，並且會在Firebase SDK中引發錯誤。將其設置爲NO將清除消息。當新的SDK出來時，你有沒有時間框架？ – User5103156

@ User5103156我們會調查ENABLE_BITCODE以及我們是否可以將其設置在火力地堡SDK。感謝您的領導！ –

這解決了我的問題。萬分感謝！ –

iOS 9 ATS和Firebase REST

回答

相關問題