iOS 9 ATS e Firebase REST

Question

Sto costruendo una semplice app iOS che parla con Firebase utilizzando l'API REST.

In sostanza, sto usando NSURLSession.sharedSession().dataTaskWithRequest per connettersi a

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

L'applicazione funziona bene in iOS 8. Sono in grado di passare GET/PUT/PATCH/DELETE per manipolare i miei dati. Ma dal momento che iOS 9 introdotto ATS, ora ho l'errore https:

NSURLSession/NSURLConnection HTTP load failed

(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake failed)

Sono pienamente consapevole della soluzione soluzione in Info.plist. Tuttavia, voglio utilizzare la nuova funzionalità di sicurezza in iOS 9.

Ho controllato la sicurezza della connessione Firebase (facendo clic sul pulsante di blocco verde di Chrome) e sembra essere compatibile con il requisito ATS di Apple.

Il mio errore è dovuto al modo in cui utilizzo NSURLSession? O è a causa della configurazione di sicurezza di Firebase?

PS: ho testato https://firebase.com e NSURLSession si collega bene senza errore. La mia app è anche abbastanza semplice da non richiedere l'autenticazione.

Grazie per il vostro aiuto.

Answer 1

TL; DR: Ha a che fare con i crittografi SSL che i server Firebase consentono (ATS richiede ECDHE solo immediatamente).

Come accennato, la soluzione in Info.plist è quello di aggiungere il seguente:

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

Nel ATS docs, Apple permette solo per i seguenti fuori dalla scatola:

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 

Impostazione NSThirdPartyExceptionRequiresForwardSecrecy in NO in Info.plist aggiunge i seguenti:

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 

Non sono d'accordo con la denominazione della bandiera come "... ExceptionRequiresForwardSecrecy" poiché tecnicamente DHE offre un perfetto segreto di inoltro, è solo più lento delle versioni ECDHE comparabili. Mi sembra che ci debbano essere due bandiere, una delle quali è l'eccezione alla segretezza in avanti e una che dice semplicemente che sei a tuo agio con una stretta di mano più lenta.

Tecnicamente è possibile anche creare il dominio escluso <your-firebase-app>.firebaseio.com e non disporre del flag NSIncludesSubdomains, ma volevo renderlo sufficientemente generico.

Dato che consentiamo crittografie non ECDHE, Firebase dovrebbe disabilitare il lato server affinché funzioni correttamente (a meno che gli sviluppatori non vogliano iniziare a lavorare con contenuti di livello inferiore a NSURLRequest, vedere this SO post per maggiori informazioni sulla configurazione Crittografie SSL, ma impiegherete più tempo a farlo piuttosto che aggiungere poche righe a Info.plist).

Per quanto riguarda la sicurezza, stiamo fornendo versioni comparabili degli stessi codici, semplicemente non utilizzando la versione Curve ellittiche (che fornisce un miglioramento delle prestazioni decente, ma escludono alcuni browser [in particolare i browser mobili]). Maggiori informazioni su DHE vs ECDHE (e qualche altro bel background SSL w.r.t Forward Secrecy è here).

Per quel che vale, i clienti in tempo reale non hanno questo problema, quindi vi consiglio vivamente usando quelli per una migliore esperienza Firebase :)