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加载失败

(kCFStreamErrorDomainSSL,CFNetwork SSLHandshake失败)

我完全了解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).

如上所述,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文档中,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更低级别的东西,请参阅此SO帖子以获取有关配置SSL密码的更多信息,但是你要花更多的时间来做这些,而不是向Info.plist添加几行.

在安全方面,我们提供相同版本的相同密码,只是不使用Elliptic Curves版本(它提供了不错的性能改进,但排除了某些浏览器[特别是移动浏览器]).有关DHE vs ECDHE的更多信息(以及其他一些不错的SSL背景和转发保密就在这里).

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