2015-07-10 4 views
7

Buduję prostą aplikację na iOS, która komunikuje się z Firebase za pomocą REST API.iOS 9 ATS i Firebase REST

Zasadniczo używam NSURLSession.sharedSession().dataTaskWithRequest połączyć się

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

Aplikacja działa poprawnie w iOS 8. Jestem w stanie przejść GET/PUT/patch/DELETE do manipulowania moje dane. Ale ponieważ iOS 9 wprowadzono ATS, teraz mam błąd https:

NSURLSession/NSURLConnection HTTP load failed

(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake failed)

Jestem w pełni świadomy roztworu obejścia w Info.plist. Jednak chcę korzystać z nowej funkcji bezpieczeństwa w iOS 9.

Sprawdziłem bezpieczeństwo połączenia Firebase (klikając na zielony przycisk blokady Chrome) i wydaje się być zgodne z wymaganiami ATS firmy Apple.

Czy mój błąd wynika ze sposobu, w jaki używam NSURLSession? A może z powodu ustawień bezpieczeństwa Firebase?

PS: Przetestowałem https://firebase.com, a NSURLSession łączy się z drobnym błędem w/o. Moja aplikacja jest również na tyle prosta, że ​​nie wymagam autoryzacji.

Dziękuję za pomoc.

+0

Trudno odgadnąć, co iOS jest niezadowolony z tego błędu. Jeśli znajdziesz sposób, by wykopać bardziej szczegółowe informacje o błędach, zrób nam wiadomość e-mail na adres [email protected] i zobaczymy, czy potrafimy wskazać, czego nie podoba się iOS w naszej konfiguracji SSL. –

+0

dziękuję. Skopiuję komunikat o błędzie i pomoc przez e-mail. – User5103156

Odpowiedz

13

TL; DR: Ma to związek z szyframi SSL Pozwól serwerom Firebase (ATS wymaga tylko ECDHE).

Jak wspomniano, obejście w Info.plist jest dodanie następujących czynności:

<key>NSAppTransportSecurity</key> 
    <dict> 
     <key>NSExceptionDomains</key> 
     <dict> 
      <key>firebaseio.com</key> 
      <dict> 
       <key>NSIncludesSubdomains</key> 
       <true/> 
       <key>NSThirdPartyExceptionRequiresForwardSecrecy</key> 
       <false/> 
      </dict> 
     </dict> 
    </dict> 

W ATS docs, Apple pozwala jedynie na następujące po wyjęciu z pudełka:

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 

Ustawianie Flaga NSThirdPartyExceptionRequiresForwardSecrecy do NO w Info.plist dodaje następujące dodatkowe:

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 

Nie zgadzam się z ich nazewnictwem flagi jako "... ExceptionRequiresForwardSecrecy", ponieważ technicznie DHE zapewnia idealną poufność w czasie rzeczywistym, jest po prostu wolniejsza od porównywalnych wersji ECDHE. Wydaje mi się, że powinny być dwie flagi, z których jedna stanowi wyjątek dla tajemnicy naprzód i taka, która mówi, że czujesz się swobodniej, mając wolniejszy uścisk dłoni.

Pod względem technicznym można również utworzyć wykluczoną domenę <your-firebase-app>.firebaseio.com i nie mieć flagi NSIncludesSubdomains, ale chciałem, aby było to wystarczająco ogólne.

Skoro pozwalamy dla niezarejestrowanych szyfrów ECDHE, Firebase musiałby zabronić im po stronie serwera za to do pracy po wyjęciu z pudełka (chyba, że ​​twórcy chcieli zacząć bawić z niższego poziomu rzeczy niż NSURLRequest patrz this SO post uzyskać więcej informacji na temat konfigurowania Szyfry SSL, ale poświęcisz więcej czasu na to, niż dodanie kilku linii do Info.plist).

Pod względem bezpieczeństwa dostarczamy porównywalne wersje tych samych szyfrów, nie korzystając z wersji Elliptic Curves (które zapewniają przyzwoitą poprawę wydajności, ale wykluczają niektóre przeglądarki (szczególnie przeglądarki mobilne)). Więcej informacji na temat DHE vs ECDHE (i kilka innych ładnych SSL tła w.r.t Forward Secrecy to here).

Na co warto, to w czasie rzeczywistym klienci nie mają tego problemu, więc gorąco polecam przy użyciu tych, dla lepszego Firebase doświadczenia :)

+2

Dziękuję za uwagi. Przełączyłem się na pakiet SDK Firebase. Chcę tylko wspomnieć o kodzie XCode 7 ustawionym na ENABLE_BITCODE na domyślnie yes i zgłaszałbym błąd w pakiecie SDK Firebase. Ustawienie na NIE spowoduje wyczyszczenie wiadomości. Czy masz jakieś ramy czasowe, kiedy pojawi się nowy SDK? – User5103156

+0

@ User5103156 Przeanalizujemy ENABLE_BITCODE i czy możemy go ustawić w pakiecie SDK Firebase. Dzięki za heads up! –

+0

To rozwiązało mój problem. Tysiące dzięki! –

Powiązane problemy