iOS 9 ATS i Firebase REST

Question

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

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.

Answer 1

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 :)