आईओएस 9 एटीएस और फायरबेस रीस्ट

Question

मैं एक साधारण आईओएस ऐप बना रहा हूं जो आरईएसटी एपीआई का उपयोग कर फायरबेस से बात करता है।

अनिवार्य रूप से, मैं NSURLSession.sharedSession().dataTaskWithRequest उपयोग कर रहा हूँ

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

को एप्लिकेशन iOS 8. में ठीक काम करता है मैं/PUT/PATCH पारित/अपने डेटा हेरफेर करने के लिए हटा करने में सक्षम हूँ कनेक्ट करने के लिए।

NSURLSession/NSURLConnection HTTP load failed

(kCFStreamErrorDomainSSL, CFNetwork SSLHandshake failed)

मैं Info.plist में समाधान समाधान से पूरी तरह वाकिफ हूं: लेकिन जब से आईओएस 9 एटीएस की शुरुआत की है, अब मैं https त्रुटि है। हालांकि, मैं आईओएस 9 में नई सुरक्षा सुविधा का उपयोग करना चाहता हूं।

मैंने फायरबेस कनेक्शन सुरक्षा (क्रोम के ग्रीन लॉक बटन पर क्लिक करके) की जांच की, और यह ऐप्पल की एटीएस आवश्यकता के साथ संगत प्रतीत होता है।

क्या मैं NSRL सत्र का उपयोग करने की वजह से मेरी त्रुटि है? या यह फ़ायरबेस सुरक्षा सेटअप की वजह से है?

पीएस: मैंने https://firebase.com का परीक्षण किया और NSURLSession ठीक w/o त्रुटि को जोड़ता है। मेरा ऐप इतना आसान है कि मुझे ऑथ की आवश्यकता नहीं है।

आपकी मदद के लिए धन्यवाद।

Answer 1

टीएल; डीआर: इसे एसएसएल सिफर के साथ करना है फायरबेस सर्वर अनुमति देता है (एटीएस को केवल बॉक्स के बाहर ईसीडीएचई की आवश्यकता होती है)।

जैसा कि बताया जा 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 docs में, एप्पल केवल बॉक्स से बाहर निम्नलिखित के लिए अनुमति देता है:

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 पर ध्वज निम्नलिखित अतिरिक्त जोड़ता है:

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 

मैं झंडा के नामकरण के साथ असहमत हूं ... "अपवाद की आवश्यकताएं फॉरवर्ड सर्विसी" तकनीकी रूप से डीएचई सही आगे की गोपनीयता प्रदान करता है, यह तुलनीय ईसीडीएचई संस्करणों की तुलना में धीमा है। मुझे लगता है कि वहां दो झंडे होनी चाहिए, एक गुप्तता को आगे बढ़ाने का अपवाद है और एक ऐसा कहता है कि आप धीमे हैंडशेक रखने में सहज हैं।

तकनीकी रूप से आप छोड़कर डोमेन <your-firebase-app>.firebaseio.com भी बना सकते हैं और NSIncludesSubdomains ध्वज नहीं है, लेकिन मैं इसे पर्याप्त सामान्य बनाना चाहता था।

चूंकि हम गैर ईसीडीएचई सिफर के लिए अनुमति देते हैं, इसलिए फ़ायरबेस को बॉक्स के बाहर काम करने के लिए सर्वर पक्ष को अस्वीकार करना होगा (जब तक डेवलपर्स NSURLRequest की तुलना में निम्न स्तर की सामग्री के साथ गड़बड़ करना शुरू नहीं करना चाहते हैं, तो कॉन्फ़िगर करने के बारे में अधिक जानकारी के लिए this SO post देखें एसएसएल सिफर, लेकिन आप Info.plist को कुछ लाइन जोड़ने से अधिक समय व्यतीत करेंगे)।

सुरक्षा के अनुसार, हम एक ही सिफर के तुलनात्मक संस्करण प्रदान कर रहे हैं, केवल एल्लिप्टिक वक्र संस्करण का उपयोग नहीं कर रहे हैं (जो एक सभ्य प्रदर्शन सुधार प्रदान करता है, लेकिन कुछ ब्राउज़रों [विशेष रूप से मोबाइल ब्राउज़र] को छोड़कर)। डीएचई बनाम ईसीडीएचई पर अधिक जानकारी (और कुछ अन्य अच्छी एसएसएल पृष्ठभूमि w.r.t फॉरवर्ड गोपनीयता here है)।

क्या इसके लायक है के लिए, वास्तविक समय ग्राहकों को इस समस्या नहीं है, तो मैं दृढ़ता से एक बेहतर Firebase अनुभव के लिए उन :)