iOS 9 个 ATS 和 Firebase REST

Question

我正在构建一个简单的 iOS 应用程序，它使用 REST API.

与 Firebase 通信

基本上，我正在使用 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 连接正常 w/o 错误。我的应用程序也很简单，不需要身份验证。

感谢您的帮助。

Answer 1

TL;DR：它与 Firebase 服务器允许的 SSL 密码有关（ATS 只需要开箱即用的 ECDHE）。[=20=]

如前所述，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 中，Apple 仅允许开箱即用：

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

在 Info.plist 中将 NSThirdPartyExceptionRequiresForwardSecrecy 标志设置为 NO 添加以下附加标志：

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 密码，Firebase 必须禁止它们在服务器端才能开箱即用（除非开发人员想开始使用比 NSURLRequest 更底层的东西，请参阅 this SO post有关配置 SSL 密码的更多信息，但与在 Info.plist).

中添加几行相比，您将花费更多时间来做这件事

在安全方面，我们提供相同密码的可比版本，只是不使用椭圆曲线版本（它提供了不错的性能改进，但不包括某些浏览器 [特别是移动浏览器]）。有关 DHE 与 ECDHE 的更多信息（以及其他一些不错的 SSL 背景 w.r.t 前向保密是 here）。

就其价值而言，实时客户端没有这个问题，所以我强烈建议使用它们以获得更好的 Firebase 体验:)

iOS 9 个 ATS 和 Firebase REST

iOS 9 ATS and Firebase REST

https

firebase

ios9