iOS 9 ATS和Firebase REST

Question

我正在构建一个简单的iOS应用程序，它使用REST与Firebase对话。

本质上，我使用NSURLSession.sharedSession().dataTaskWithRequest连接到

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

该应用程序在iOS 8中运行良好，我可以通过GET/PUT/补丁/DELETE来操作我的数据。但是自从iOS 9引入ATS之后，我现在有了https错误：

NSURLSession/NSURLConnection HTTP负载失败 (kCFStreamErrorDomainSSL，CFNetwork SSLHandshake失败)

我完全了解Info.plist中的解决方案。但是，，我想利用iOS 9中的新安全特性。

我检查了Firebase连接安全性(点击Chrome的绿色锁按钮)，它似乎与苹果的ATS要求兼容。

我的错误是因为我使用NSURLSession的方式吗？还是因为Firebase安全设置？

PS:我测试了https://firebase.com和NSURLSession连接很好的w/o错误。我的应用程序也很简单，所以我不需要使用。

谢谢你的帮助。

Answer 1

TL;DR:这与SSL密码Firebase服务器所允许的(ATS只需要开箱即用)有关。

如前所述，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文档中，苹果只允许开箱即用：

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标志设置为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低的东西，请参阅这是如此的帖子获取有关配置SSL密码的更多信息，但您将花费更多的时间来完成这一任务，而不是向Info.plist添加几行代码)。

在安全性方面，我们提供相同密码的类似版本，只是不使用椭圆曲线版本(它提供了不错的性能改进，但排除了某些浏览器，特别是移动浏览器)。关于DHE与ECDHE的更多信息(以及其他一些不错的SSL背景w.r.t转发保密是这里)。

值得注意的是，实时客户端没有这个问题，因此我强烈建议您使用这些客户端来获得更好的Firebase体验:)