iOS 9 ATS и Firebase REST

Я создаю простое приложение для iOS, которое взаимодействует с Firebase с помощью REST API.

По сути, я использую NSURLSession.sharedSession().dataTaskWithRequest для подключения к

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

Приложение отлично работает в iOS 8. Я могу передать GET/PUT/PATCH/DELETE для управления своими данными. Но так как iOS 9 представила ATS, теперь у меня есть ошибка https:

Ошибка HTTP-загрузки NSURLSession/NSURLConnection

(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake не удалось)

Мне полностью известно об обходном решении в Info.plist. Однако я хочу использовать новую функцию безопасности в iOS 9.

Я проверил безопасность подключения к Firebase (нажав зеленую кнопку блокировки Chrome), и, похоже, она совместима с требованием Apple ATS.

Моя ошибка связана с тем, как я использую NSURLSession? Или это из-за настройки безопасности Firebase?

PS: я протестировал https://firebase.com, и NSURLSession подключается нормально, без ошибок. Мое приложение также достаточно простое, поэтому мне не требуется авторизация.

Спасибо за помощь.


person User5103156    schedule 10.07.2015    source источник
comment
Трудно предположить, чем iOS недовольна из-за этой ошибки. Если вы найдете способ найти более подробную информацию об ошибках, отправьте нам электронное письмо по адресу [email protected], и мы посмотрим, сможем ли мы точно определить, что iOS не нравится в нашей конфигурации SSL.   -  person Michael Lehenbauer    schedule 11.07.2015
comment
благодарю вас. Я скопирую сообщение об ошибке и по электронной почте поддержки.   -  person User5103156    schedule 11.07.2015


Ответы (1)


TL;DR: это связано с SSL-шифрами, которые позволяют серверы Firebase (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

Установка флага 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, Firebase должен будет запретить их на стороне сервера, чтобы это работало из коробки (если только разработчики не захотят начать возиться с вещами более низкого уровня, чем NSURLRequest, см. это сообщение SO для получения дополнительной информации о настройке шифров SSL, но вы потратите на это больше времени, чем на добавление несколько строк в Info.plist).

Что касается безопасности, мы предоставляем сопоставимые версии тех же шифров, просто не используя версию на эллиптических кривых (которая обеспечивает приличное улучшение производительности, но исключает определенные браузеры [особенно мобильные браузеры]). Дополнительная информация о DHE и ECDHE (и некоторые другие полезные сведения о SSL в отношении Forward Secrecy: здесь).

Как бы то ни было, клиенты реального времени не имеют этой проблемы, поэтому я настоятельно рекомендую использовать их для лучшего взаимодействия с Firebase :)

person Mike McDonald    schedule 12.07.2015
comment
Спасибо за ваши Коментарии. Я перешел на Firebase SDK. Просто хочу упомянуть, что XCode 7 по умолчанию устанавливает для ENABLE_BITCODE значение yes и выдает ошибку с Firebase SDK. Если установить значение NO, сообщение исчезнет. Есть ли у вас какие-то сроки, когда выйдет новый SDK? - person User5103156; 13.07.2015
comment
@ User5103156 Мы рассмотрим ENABLE_BITCODE и можем ли мы установить его в Firebase SDK. Спасибо за внимание! - person Michael Lehenbauer; 13.07.2015
comment
Как относительно безболезненная, но, возможно, менее безопасная альтернатива: github.com/leecrossley/cordova-plugin-transport-security - person brandones; 30.09.2015
comment
Я сделал все вышеперечисленное, но по-прежнему получаю сообщение об ошибке CFNetwork SSLHandshake failed (-9806) только когда устройство заблокировано. Использование объективной версии SDK stackoverflow.com/questions /33922796/ - будем признательны за любую помощь :) - person Mark Camilleri; 07.12.2015
comment
У меня отключен биткод, и я все еще получаю сообщение об ошибке - person ArdenDev; 04.08.2016