iOS 9 ATS和Firebase REST [英] iOS 9 ATS and Firebase REST
问题描述
基本上，我使用
NSURLSession.sharedSession（）。dataTaskWithRequest 连接到
https://myusername.firebaseio.com/ Object.json
该应用程序在iOS 8中正常工作。我可以通过GET / PUT / PATCH / DELETE操纵我的数据。但是，由于iOS 9引入了ATS，我现在有https错误：
$ b
NSURLSession / NSURLConnection HTTP加载失败
（kCFStreamErrorDomainSSL，CFNetwork SSLHandshake失败）
我完全了解Info中的解决方法但是，我想利用iOS 9中的新安全功能。
我检查了Firebase连接安全性（通过点击Chrome的绿色锁定按钮） ，而且这似乎与苹果的ATS要求兼容。
我的错误是因为我使用NSURLSession的方式吗？还是因为Firebase安全设置？ PS：我测试了 https://firebase.com 和NSURLSession连接很好的W / O错误。我的应用程序也很简单，我不需要授权。
感谢您的帮助。 TL：DR：它与Firebase服务器允许的SSL密码有关（ATS只需要开箱即可使用ECDHE） 。
如前所述，Info.plist中的解决方法是添加以下内容：
<密钥GT; NSAppTransportSecurity< /密钥GT;
< dict>
< key> NSExceptionDomains< / key>
< dict>
< key> firebaseio.com< / key>
< dict>
< key> NSIncludesSubdomains< / key>
< true />
< key> NSThirdPartyExceptionRequiresForwardSecrecy< / key>
< false />
< / dict>
< / dict>
< / dict>
在 ATS docs ，苹果只允许以下开箱：
'pre>
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_RS A_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
DHE提供的技术上，我不同意他们的国旗的命名为... ExceptionRequiresForwardSecrecy完美的前向保密性，只比同类ECDHE版慢。听起来对我来说，应该有两个标志，一个是提出保密的例外，一个只是说你可以放心握手。
技术上你可以也使得例外的域名< your-firebase-app> .firebaseio.com 并没有 NSIncludesSubdomains 标志，但是我想使它具有足够的通用性。
由于我们允许使用非ECDHE密码，因此Firebase将不得不禁止它们在服务器端进行工作（除非开发人员想要开始与NSURLRequest相比较低层次的东西，参见这个SO post ，以获取更多有关配置SSL密码的信息，但是您将花费更多的时间来做这件事，而不是添加几行Info.plist）。
$ b
明智的是，我们提供了相同的密码版本，只是没有使用椭圆曲线版本（提供了不错的性能提升，但排除了某些浏览器（特别是移动浏览器））。有关DHE与ECDHE的更多信息（以及其他一些不错的SSL背景与前向保密是这里）。
实时客户端没有这个问题，所以我强烈建议使用这些更好的Firebase体验：）
I am building a simple iOS app that talks to Firebase using REST API.
Essentially, I am using NSURLSession.sharedSession().dataTaskWithRequest to connect to
The app works fine in iOS 8. I am able to pass GET/PUT/PATCH/DELETE to manipulate my data. But since iOS 9 introduced ATS, I now have the https error:
NSURLSession/NSURLConnection HTTP load failed
(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake failed)
I am fully aware of the workaround solution in Info.plist. However, I want to utilize the new safety feature in iOS 9.
I checked Firebase connection security (by clicking on Chrome's green lock button), and it seems to be compatible with Apple's ATS requirement.
Is my error because of the way I use NSURLSession? Or is it because of the Firebase security setup?
PS: I tested https://firebase.com and NSURLSession connects fine w/o error. My app is also simple enough that I don't require auth.
Thank you for your help.
解决方案 TL;DR: It has to do with the SSL ciphers Firebase servers allow (ATS requires ECDHE only out of the box).
As mentioned, the workaround in Info.plist is to add the following:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>firebaseio.com</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
</dict>
In the ATS docs, Apple only allows for the following out of the box:
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
Setting the NSThirdPartyExceptionRequiresForwardSecrecy flag to NO in Info.plist adds the following additional ones:
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
I disagree with their naming of the flag to be "...ExceptionRequiresForwardSecrecy" since technically DHE provides perfect forward secrecy, it's just slower than the comparable ECDHE versions. Sounds to me like there should be two flags, one being the exception to forward secrecy and one that just says that you're comfortable having a slower handshake.
Technically you could also make the excepted domain <your-firebase-app>.firebaseio.com and not have the NSIncludesSubdomains flag, but I wanted to make this sufficiently generic.
Since we allow for non ECDHE ciphers, Firebase would have to disallow them server side for this to work out of the box (unless developers wanted to start messing around with lower level stuff than NSURLRequest, see this SO post for more info on configuring SSL ciphers, but you'll spend more time doing that than adding a few lines to Info.plist).
Security-wise, we're providing comparable versions of the same ciphers, just not using the Elliptic Curves version (which provide a decent performance improvement, but exclude certain browsers [particularly mobile browsers]). More info on DHE vs ECDHE (and some other nice SSL background w.r.t Forward Secrecy is here).
For what it's worth, the realtime clients don't have this problem, so I would strongly recommend using those for a better Firebase experience :)
这篇关于iOS 9 ATS和Firebase REST的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
