नेटवर्क प्रोटोकॉल की मदद से सुरक्षा

क्लाइंट-सर्वर एन्क्रिप्ट किए गए इंटरैक्शन, आपके ऐप्लिकेशन के डेटा को सुरक्षित रखने के लिए, ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) का इस्तेमाल करते हैं.

इस लेख में, सुरक्षित नेटवर्क प्रोटोकॉल के सबसे सही तरीकों और पब्लिक-की इन्फ़्रास्ट्रक्चर (पीकेआई) के बारे में बताया गया है. ज़्यादा जानकारी के लिए, Android सुरक्षा की खास जानकारी और अनुमतियों की खास जानकारी पढ़ें.

कॉन्सेप्ट

TLS सर्टिफ़िकेट वाले सर्वर में एक सार्वजनिक पासकोड और उससे मैच होने वाली निजी पासकोड होती है. सर्वर, TLS हैंडशेक के दौरान अपने सर्टिफ़िकेट पर हस्ताक्षर करने के लिए, सार्वजनिक पासकोड क्रिप्टोग्राफ़ी का इस्तेमाल करता है.

सामान्य हैंडशेक से सिर्फ़ यह पता चलता है कि सर्वर के पास सर्टिफ़िकेट की निजी कुंजी है. इस स्थिति को ठीक करने के लिए, क्लाइंट को एक से ज़्यादा सर्टिफ़िकेट पर भरोसा करने दें. अगर किसी सर्वर का सर्टिफ़िकेट, क्लाइंट-साइड के भरोसेमंद सर्टिफ़िकेट के सेट में नहीं दिखता है, तो वह सर्वर भरोसेमंद नहीं है.

हालांकि, सर्वर अपने सर्टिफ़िकेट की सार्वजनिक कुंजी को नई कुंजी से बदलने के लिए, कुंजी रोटेशन का इस्तेमाल कर सकते हैं. सर्वर कॉन्फ़िगरेशन में बदलाव करने के लिए, क्लाइंट ऐप्लिकेशन को अपडेट करना ज़रूरी है. अगर सर्वर, तीसरे पक्ष की वेब सेवा है, जैसे कि वेब ब्राउज़र या ईमेल ऐप्लिकेशन, तो यह जानना मुश्किल हो जाता है कि क्लाइंट ऐप्लिकेशन को कब अपडेट करना है.

आम तौर पर, सर्टिफ़िकेट जारी करने के लिए सर्वर, सर्टिफ़िकेट देने वाली संस्थाओं (सीए) के सर्टिफ़िकेट पर भरोसा करते हैं. इससे समय के साथ क्लाइंट-साइड कॉन्फ़िगरेशन ज़्यादा स्थिर रहता है. सीए, अपनी निजी कुंजी का इस्तेमाल करके, सर्वर सर्टिफ़िकेट पर साइन करता है. इसके बाद, क्लाइंट यह जांच कर सकता है कि सर्वर के पास, प्लैटफ़ॉर्म के लिए मान्य सीए सर्टिफ़िकेट है या नहीं.

भरोसेमंद सीए आम तौर पर होस्ट प्लैटफ़ॉर्म पर मौजूद होते हैं. Android 8.0 (एपीआई लेवल 26) में 100 से ज़्यादा सीए शामिल हैं. ये हर वर्शन में अपडेट होते हैं और डिवाइसों के बीच नहीं बदलते.

क्लाइंट ऐप्लिकेशन को सर्वर की पुष्टि करने के लिए एक तरीके की ज़रूरत होती है, क्योंकि सीए कई सर्वर के लिए सर्टिफ़िकेट उपलब्ध कराता है. सीए का सर्टिफ़िकेट, gmail.com जैसे किसी खास नाम या *.google.com जैसे वाइल्डकार्ड का इस्तेमाल करके सर्वर की पहचान करता है.

किसी वेबसाइट के सर्वर सर्टिफ़िकेट की जानकारी देखने के लिए, openssl टूल के s_client कमांड का इस्तेमाल करें. साथ ही, पोर्ट नंबर डालें. डिफ़ॉल्ट रूप से, एचटीटीपीएस पोर्ट 443 का इस्तेमाल करता है.

यह कमांड, openssl s_client आउटपुट को openssl x509 पर भेजता है. यह X.509 स्टैंडर्ड में सर्टिफ़िकेट की जानकारी को फ़ॉर्मैट करता है. यह कमांड, विषय (सर्वर का नाम) और जारी करने वाले (सीए) का अनुरोध करता है.

openssl s_client -connect WEBSITE-URL:443 | \
  openssl x509 -noout -subject -issuer

एचटीटीपीएस का उदाहरण

मान लें कि आपके पास किसी मशहूर सीए से जारी किया गया सर्टिफ़िकेट वाला वेब सर्वर है, तो नीचे दिए गए कोड में दिखाए गए तरीके से सुरक्षित अनुरोध किया जा सकता है:

Kotlin

val url = URL("https://wikipedia.org")
val urlConnection: URLConnection = url.openConnection()
val inputStream: InputStream = urlConnection.getInputStream()
copyInputStreamToOutputStream(inputStream, System.out)

Java

URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

एचटीटीपी अनुरोधों को पसंद के मुताबिक बनाने के लिए, HttpURLConnection पर कास्ट करें. Android HttpURLConnection दस्तावेज़ में, अनुरोध और रिस्पॉन्स हेडर मैनेज करने, कॉन्टेंट पब्लिश करने, कुकी मैनेज करने, प्रोक्सी का इस्तेमाल करने, रिस्पॉन्स कैश मेमोरी में सेव करने वगैरह के उदाहरण शामिल हैं. Android फ़्रेमवर्क, इन एपीआई का इस्तेमाल करके सर्टिफ़िकेट और होस्टनेम की पुष्टि करता है.

जब भी हो सके, इन एपीआई का इस्तेमाल करें. इस सेक्शन में, आम तौर पर होने वाली ऐसी समस्याओं के बारे में बताया गया है जिनके लिए अलग-अलग समाधान ज़रूरी हैं.

सर्वर सर्टिफ़िकेट की पुष्टि करने में आने वाली सामान्य समस्याएं

मान लें कि कॉन्टेंट दिखाने के बजाय, getInputStream(), एक अपवाद दिखाता है:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
        at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
        at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

ऐसा कई वजहों से हो सकता है. इनमें ये वजहें शामिल हैं:

  1. सर्वर सर्टिफ़िकेट जारी करने वाला सीए अज्ञात था.
  2. सर्वर सर्टिफ़िकेट पर, सीए का हस्ताक्षर नहीं है, लेकिन उस पर खुद का हस्ताक्षर है.
  3. सर्वर कॉन्फ़िगरेशन में इंटरमीडियरी सीए मौजूद नहीं है.

नीचे दिए गए सेक्शन में, सर्वर से सुरक्षित तरीके से कनेक्ट रहते हुए इन समस्याओं को हल करने का तरीका बताया गया है.

सर्टिफ़िकेट देने वाली संस्था की जानकारी नहीं है

SSLHandshakeException गड़बड़ी इसलिए होती है, क्योंकि सिस्टम सीए पर भरोसा नहीं करता. ऐसा इसलिए हो सकता है कि आपके पास किसी ऐसे नए सीए का सर्टिफ़िकेट हो जिस पर Android भरोसा नहीं करता. इसके अलावा, ऐसा भी हो सकता है कि आपका ऐप्लिकेशन, सीए के बिना किसी पुराने वर्शन पर काम कर रहा हो. यह निजी होता है, इसलिए सीए के बारे में बहुत कम लोगों को पता होता है. आम तौर पर, किसी सीए के बारे में जानकारी नहीं होती, क्योंकि वह सार्वजनिक सीए नहीं होता. वह किसी संगठन, जैसे कि सरकार, कॉर्पोरेशन या शिक्षा संस्थान के लिए जारी किया गया निजी सीए होता है.

अपने ऐप्लिकेशन के कोड में बदलाव किए बिना, कस्टम सीए पर भरोसा करने के लिए, नेटवर्क सुरक्षा कॉन्फ़िगरेशन बदलें.

चेतावनी: कई वेबसाइटों पर, समस्या को हल करने का एक गलत तरीका बताया गया है. इसके तहत, एक ऐसा TrustManager इंस्टॉल करना है जो कुछ काम नहीं करता. ऐसा करने पर, सार्वजनिक वाई-फ़ाई हॉटस्पॉट का इस्तेमाल करने पर आपके उपयोगकर्ताओं को हमलों का खतरा रहता है. ऐसा इसलिए, क्योंकि हमलावर डीएनएस की तरकीबों का इस्तेमाल करके, आपके उपयोगकर्ताओं के ट्रैफ़िक को किसी ऐसे प्रॉक्सी के ज़रिए भेज सकता है जो आपके सर्वर के तौर पर काम करता है. इसके बाद, हमलावर पासवर्ड और अन्य निजी डेटा रिकॉर्ड कर सकता है. ऐसा इसलिए होता है, क्योंकि हमलावर सर्टिफ़िकेट जनरेट कर सकता है. साथ ही, TrustManager के बिना इस बात की पुष्टि करना कि सर्टिफ़िकेट किसी भरोसेमंद सोर्स से मिला है, इस तरह के हमले को ब्लॉक नहीं किया जा सकता. इसलिए, ऐसा न करें, भले ही कुछ समय के लिए ही सही. इसके बजाय, अपने ऐप्लिकेशन को सर्वर के सर्टिफ़िकेट जारी करने वाले पर भरोसा करने दें.

खुद हस्ताक्षर किया गया सर्वर सर्टिफ़िकेट

दूसरा, SSLHandshakeException गड़बड़ी, खुद के हस्ताक्षर वाले सर्टिफ़िकेट की वजह से हो सकती है. इससे सर्वर, खुद को CA बना लेता है. यह किसी अज्ञात सर्टिफ़िकेट देने वाली संस्था की तरह है. इसलिए, अपने ऐप्लिकेशन के नेटवर्क सुरक्षा कॉन्फ़िगरेशन में बदलाव करें, ताकि आप खुद के हस्ताक्षर वाले सर्टिफ़िकेट पर भरोसा कर सकें.

इंटरमीडिएट सर्टिफ़िकेट देने वाली संस्था या निकाय की जानकारी मौजूद नहीं है

तीसरा, SSLHandshakeException गड़बड़ी, इंटरमीडियरी सीए मौजूद न होने की वजह से होती है. सार्वजनिक सीए, सर्वर सर्टिफ़िकेट पर शायद ही कभी हस्ताक्षर करते हैं. इसके बजाय, रूट सीए, इंटरमीडिएट सीए के लिए हस्ताक्षर करता है.

सीए, रूट सीए को ऑफ़लाइन रखते हैं, ताकि हैक होने का जोखिम कम हो. हालांकि, Android जैसे ऑपरेटिंग सिस्टम आम तौर पर सिर्फ़ रूट सीए पर भरोसा करते हैं. इससे, इंटरमीडियरी सीए के हस्ताक्षर वाले सर्वर सर्टिफ़िकेट और सर्टिफ़िकेट की पुष्टि करने वाले टूल के बीच भरोसे की कमी रह जाती है. यह टूल, रूट सीए को पहचानता है.

इस भरोसे की कमी को दूर करने के लिए, सर्वर टीएलएस हैंडशेक के दौरान, सर्वर सीए से किसी भी इंटरमीडियरी के ज़रिए, भरोसेमंद रूट सीए को सर्टिफ़िकेट की एक चेन भेजता है.

उदाहरण के लिए, mail.google.com सर्टिफ़िकेट की चेन, openssl s_client कमांड से इस तरह दिखती है:

$ openssl s_client -connect mail.google.com:443
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---

इससे पता चलता है कि सर्वर, Thawte SGC सीए से जारी किया गया mail.google.com के लिए एक सर्टिफ़िकेट भेजता है. यह एक इंटरमीडियरी सीए है. साथ ही, Thawte SGC सीए के लिए Verisign सीए से जारी किया गया दूसरा सर्टिफ़िकेट भी भेजता है. यह प्राइमरी सीए है और Android इसे भरोसेमंद मानता है.

हालांकि, हो सकता है कि किसी सर्वर को ज़रूरी इंटरमीडियरी सीए को शामिल करने के लिए कॉन्फ़िगर न किया गया हो. उदाहरण के लिए, यहां एक ऐसा सर्वर दिया गया है जिसकी वजह से Android ब्राउज़र में गड़बड़ी हो सकती है और Android ऐप्लिकेशन में अपवाद दिख सकते हैं:

$ openssl s_client -connect egov.uscis.gov:443
---
Certificate chain
 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---

अज्ञात सीए या खुद के हस्ताक्षर वाले सर्वर सर्टिफ़िकेट के उलट, ज़्यादातर डेस्कटॉप ब्राउज़र इस सर्वर से कनेक्ट करते समय गड़बड़ी नहीं दिखाते. डेस्कटॉप ब्राउज़र, भरोसेमंद इंटरमीडियरी सीए को कैश मेमोरी में सेव करते हैं. किसी साइट से इंटरमीडियरी सीए के बारे में जानने के बाद, ब्राउज़र को सर्टिफ़िकेट चेन में फिर से उसकी ज़रूरत नहीं होगी.

कुछ साइटें, संसाधन देने वाले सेकंडरी वेब सर्वर के लिए जान-बूझकर ऐसा करती हैं. बैंडविड्थ बचाने के लिए, वे अपने मुख्य एचटीएमएल पेज को ऐसे सर्वर से दिखा सकते हैं जिसमें पूरी सर्टिफ़िकेट चेन हो, लेकिन उनकी इमेज, सीएसएस, और JavaScript में सीए न हो. माफ़ करें, कभी-कभी ये सर्वर ऐसी वेब सेवा दे सकते हैं जिसे आप अपने Android ऐप्लिकेशन से ऐक्सेस करने की कोशिश कर रहे हैं. यह सेवा, ज़्यादा समय तक काम नहीं करती.

इस समस्या को ठीक करने के लिए, सर्वर को कॉन्फ़िगर करें, ताकि सर्वर चेन में इंटरमीडियरी सीए शामिल हो सके. ज़्यादातर सीए, सामान्य वेब सर्वर के लिए ऐसा करने का तरीका बताते हैं.

सीधे तौर पर SSLSocket का इस्तेमाल करने के बारे में चेतावनियां

अब तक, उदाहरणों में HttpsURLConnection का इस्तेमाल करके एचटीटीपीएस पर फ़ोकस किया गया है. कभी-कभी ऐप्लिकेशन को एचटीटीपीएस के अलावा, अलग से TLS का इस्तेमाल करना पड़ता है. उदाहरण के लिए, कोई ईमेल ऐप्लिकेशन, SMTP, POP3 या आईएमएपी के TLS वैरिएंट का इस्तेमाल कर सकता है. ऐसे मामलों में, ऐप्लिकेशन सीधे तौर पर SSLSocket का इस्तेमाल कर सकता है, ठीक उसी तरह जैसे HttpsURLConnection अपने अंदर करता है.

सर्टिफ़िकेट की पुष्टि से जुड़ी समस्याओं को हल करने के लिए, अब तक बताई गई तकनीकें SSLSocket पर भी लागू होती हैं. दरअसल, कस्टम TrustManager का इस्तेमाल करने पर, HttpsURLConnection को SSLSocketFactory पास किया जाता है. इसलिए, अगर आपको किसी SSLSocket के साथ कस्टम TrustManager का इस्तेमाल करना है, तो वही चरण अपनाएं और SSLSocket बनाने के लिए उस SSLSocketFactory का इस्तेमाल करें.

चेतावनी: SSLSocket, होस्टनेम की पुष्टि नहीं करता. होस्टनेम की पुष्टि करना, आपके ऐप्लिकेशन के लिए ज़रूरी है. इसके लिए, getDefaultHostnameVerifier() को अनुमानित होस्टनेम के साथ कॉल करें. साथ ही, ध्यान रखें कि HostnameVerifier.verify(), गड़बड़ी होने पर कोई अपवाद नहीं दिखाता. इसके बजाय, यह एक बूलियन नतीजा दिखाता है, जिसकी आपको साफ़ तौर पर जांच करनी होगी.

सर्टिफ़िकेट की पुष्टि करना

TLS, सिर्फ़ सर्वर और डोमेन के पुष्टि किए गए मालिकों को सर्टिफ़िकेट जारी करने के लिए, सीए पर निर्भर करता है. कुछ मामलों में, सीए को धोखा दिया जाता है या Comodo या DigiNotar के मामले में, उनके पास से जानकारी हासिल की जाती है. इससे, होस्टनेम के लिए सर्टिफ़िकेट, सर्वर या डोमेन के मालिक के बजाय किसी और को जारी किए जाते हैं.

इस जोखिम को कम करने के लिए, Android पूरे सिस्टम में सर्टिफ़िकेट रद्द करने की प्रोसेस को मैनेज करता है. इसके लिए, ब्लॉकलिस्ट और सर्टिफ़िकेट ट्रांसपेरेंसी का इस्तेमाल किया जाता है. इसमें, सर्टिफ़िकेट की ऑनलाइन पुष्टि की ज़रूरत नहीं होती. इसके अलावा, Android, टीएलएस हैंडशेक के साथ स्टेपल किए गए ओसीएसपी रिस्पॉन्स की पुष्टि करेगा.

अपने ऐप्लिकेशन में सर्टिफ़िकेट ट्रांसपेरेंसी को चालू करने के लिए, नेटवर्क सुरक्षा कॉन्फ़िगरेशन के दस्तावेज़ में, सर्टिफ़िकेट ट्रांसपेरेंसी के लिए ऑप्ट इन करें सेक्शन देखें.

अपने ऐप्लिकेशन को कुछ खास सर्टिफ़िकेट के लिए सीमित करना

चेतावनी: सर्टिफ़िकेट पिन करने का सुझाव, Android ऐप्लिकेशन के लिए नहीं दिया जाता. इस प्रोसेस में, आपके ऐप्लिकेशन के लिए मान्य सर्टिफ़िकेट को सीमित कर दिया जाता है. आने वाले समय में सर्वर कॉन्फ़िगरेशन में होने वाले बदलावों, जैसे कि किसी दूसरे सीए पर स्विच करने से, पिन किए गए सर्टिफ़िकेट वाले ऐप्लिकेशन, क्लाइंट सॉफ़्टवेयर अपडेट के बिना सर्वर से कनेक्ट नहीं कर पाते.

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

क्लाइंट सर्टिफ़िकेट

इस लेख में, सर्वर के साथ सुरक्षित तरीके से कम्यूनिकेट करने के लिए, TLS के इस्तेमाल के बारे में बताया गया है. TLS, क्लाइंट सर्टिफ़िकेट की सुविधा भी देता है. इससे सर्वर, क्लाइंट की पहचान की पुष्टि कर सकता है. इस लेख में इस बारे में नहीं बताया गया है, लेकिन इसमें इस्तेमाल की गई तकनीकें, कस्टम TrustManager तय करने जैसी ही हैं.

Nogotofail: नेटवर्क ट्रैफ़िक की सुरक्षा की जांच करने वाला टूल

Nogotofail एक ऐसा टूल है जिसकी मदद से, यह पुष्टि करना आसान हो जाता है कि आपके ऐप्लिकेशन, TLS/SSL से जुड़ी जोखिम की संभावनाओं और गलत कॉन्फ़िगरेशन से सुरक्षित हैं या नहीं. यह एक ऑटोमेटेड, बेहतर, और स्केलेबल टूल है. इसका इस्तेमाल, किसी भी ऐसे डिवाइस पर नेटवर्क की सुरक्षा से जुड़ी समस्याओं की जांच करने के लिए किया जा सकता है जिसका नेटवर्क ट्रैफ़िक इस टूल से गुज़र सकता है.

Nogotofail का इस्तेमाल, तीन मुख्य कामों के लिए किया जा सकता है:

  • गड़बड़ियां और जोखिम की आशंकाएं ढूंढना.
  • समस्याओं को ठीक करने की पुष्टि करना और यह देखना कि समस्याएं फिर से न आएं.
  • यह समझना कि कौनसे ऐप्लिकेशन और डिवाइस, कौनसा ट्रैफ़िक जनरेट कर रहे हैं.

Nogotofail, Android, iOS, Linux, Windows, ChromeOS, macOS, और इंटरनेट से कनेक्ट करने के लिए इस्तेमाल किए जाने वाले किसी भी डिवाइस पर काम करता है. Android और Linux पर सेटिंग कॉन्फ़िगर करने और सूचनाएं पाने के लिए, एक क्लाइंट उपलब्ध है. साथ ही, अटैक इंजन को राउटर, वीपीएन सर्वर या प्रॉक्सी के तौर पर डिप्लॉय किया जा सकता है.

इस टूल को Nogotofail ओपन सोर्स प्रोजेक्ट पर ऐक्सेस किया जा सकता है.

एसएसएल और टीएलएस से जुड़े अपडेट

Android 10

Google Chrome जैसे कुछ ब्राउज़र, उपयोगकर्ताओं को सर्टिफ़िकेट चुनने की अनुमति देते हैं. ऐसा तब होता है, जब टीएलएस सर्वर, टीएलएस हैंडशेक के हिस्से के तौर पर, सर्टिफ़िकेट का अनुरोध करने वाला मैसेज भेजता है. Android 10 के बाद, KeyChain ऑब्जेक्ट, उपयोगकर्ताओं को सर्टिफ़िकेट चुनने का प्रॉम्प्ट दिखाने के लिए, KeyChain.choosePrivateKeyAlias() को कॉल करते समय, जारी करने वालों और पासकोड की खास जानकारी वाले पैरामीटर का इस्तेमाल करते हैं. खास तौर पर, इस प्रॉम्प्ट में ऐसे विकल्प शामिल नहीं होते जो सर्वर की ज़रूरी शर्तों के मुताबिक न हों.

अगर उपयोगकर्ता के पास चुनने के लिए कोई सर्टिफ़िकेट उपलब्ध नहीं है, तो सर्टिफ़िकेट चुनने का प्रॉम्प्ट नहीं दिखता. ऐसा तब होता है, जब कोई सर्टिफ़िकेट, सर्वर की खास बातों से मेल न खाता हो या किसी डिवाइस में कोई सर्टिफ़िकेट इंस्टॉल न किया गया हो.

इसके अलावा, Android 10 या इसके बाद के वर्शन पर, KeyChain ऑब्जेक्ट में पासकोड या सीए सर्टिफ़िकेट इंपोर्ट करने के लिए, डिवाइस का स्क्रीन लॉक होना ज़रूरी नहीं है.

TLS 1.3 डिफ़ॉल्ट रूप से चालू है

Android 10 और इसके बाद के वर्शन में, सभी TLS कनेक्शन के लिए TLS 1.3 डिफ़ॉल्ट रूप से चालू होता है. TLS 1.3 को लागू करने के बारे में कुछ अहम जानकारी यहां दी गई है:

  • TLS 1.3 साइफ़र सुइट को पसंद के मुताबिक नहीं बनाया जा सकता. TLS 1.3 चालू होने पर, काम करने वाले TLS 1.3 साइफ़र सुइट हमेशा चालू रहते हैं. setEnabledCipherSuites() को कॉल करके, उन्हें बंद करने की कोशिश को अनदेखा कर दिया जाता है.
  • TLS 1.3 के इस्तेमाल पर, सेशन कैश मेमोरी में सेशन जोड़ने से पहले, HandshakeCompletedListener ऑब्जेक्ट को कॉल किया जाता है. (TLS 1.2 और पिछले वर्शन में, सेशन को सेशन कैश में जोड़ने के बाद इन ऑब्जेक्ट को कॉल किया जाता है.)
  • कुछ मामलों में, SSLEngine इंस्टेंस Android के पिछले वर्शन पर SSLHandshakeException दिखाते हैं. वहीं, Android 10 और उसके बाद के वर्शन पर ये इंस्टेंस SSLProtocolException दिखाते हैं.
  • 0-RTT मोड काम नहीं करता.

अगर ज़रूरत हो, तो SSLContext.getInstance("TLSv1.2") को कॉल करके, ऐसा SSLContext पाया जा सकता है जिसमें TLS 1.3 बंद हो. किसी ऑब्जेक्ट पर setEnabledProtocols() को कॉल करके, हर कनेक्शन के हिसाब से प्रोटोकॉल वर्शन को चालू या बंद भी किया जा सकता है.

SHA-1 से हस्ताक्षर किए गए सर्टिफ़िकेट पर, TLS में भरोसा नहीं किया जाता

Android 10 में, SHA-1 हैश एल्गोरिदम का इस्तेमाल करने वाले सर्टिफ़िकेट, TLS कनेक्शन में भरोसेमंद नहीं माने जाते. रूट सीए ने 2016 से इस तरह के सर्टिफ़िकेट जारी नहीं किए हैं. साथ ही, Chrome या अन्य मुख्य ब्राउज़र अब इन पर भरोसा नहीं करते.

अगर कनेक्ट करने की कोशिश किसी ऐसी साइट से की जाती है जो SHA-1 का इस्तेमाल करके सर्टिफ़िकेट दिखाती है, तो कनेक्ट नहीं हो पाता.

KeyChain के काम करने के तरीके में हुए बदलाव और सुधार

Google Chrome जैसे कुछ ब्राउज़र, उपयोगकर्ताओं को सर्टिफ़िकेट चुनने की अनुमति देते हैं. ऐसा तब होता है, जब टीएलएस सर्वर, टीएलएस हैंडशेक के हिस्से के तौर पर सर्टिफ़िकेट का अनुरोध करने वाला मैसेज भेजता है. Android 10 के बाद, KeyChain ऑब्जेक्ट, KeyChain.choosePrivateKeyAlias() को कॉल करते समय, सर्टिफ़िकेट चुनने का अनुरोध दिखाने के लिए, सर्टिफ़िकेट जारी करने वाली संस्थाओं और खास जानकारी वाले पैरामीटर का इस्तेमाल करते हैं. खास तौर पर, इस प्रॉम्प्ट में ऐसे विकल्प नहीं होते जो सर्वर की ज़रूरी शर्तों के मुताबिक न हों.

अगर उपयोगकर्ता के पास चुनने के लिए कोई सर्टिफ़िकेट उपलब्ध नहीं है, तो सर्टिफ़िकेट चुनने का अनुरोध नहीं दिखता. ऐसा तब होता है, जब कोई सर्टिफ़िकेट, सर्वर की स्पेसिफ़िकेशन से मेल न खाता हो या किसी डिवाइस में कोई सर्टिफ़िकेट इंस्टॉल न हो.

इसके अलावा, Android 10 या इसके बाद के वर्शन पर, KeyChain ऑब्जेक्ट में पासकोड या सीए सर्टिफ़िकेट इंपोर्ट करने के लिए, डिवाइस का स्क्रीन लॉक होना ज़रूरी नहीं है.

TLS और क्रिप्टोग्राफ़ी से जुड़े अन्य बदलाव

TLS और क्रिप्टोग्राफ़ी लाइब्रेरी में कुछ छोटे बदलाव हुए हैं. ये बदलाव Android 10 पर लागू होंगे:

  • AES/GCM/NoPadding और ChaCha20/Poly1305/NoPadding सिफर, getOutputSize() से ज़्यादा सटीक बफ़र साइज़ दिखाते हैं.
  • TLS_FALLBACK_SCSV सिफर सुइट को, ज़्यादा से ज़्यादा TLS 1.2 या उससे ज़्यादा के प्रोटोकॉल के साथ कनेक्शन की कोशिशों से हटा दिया जाता है. TLS सर्वर को लागू करने के तरीकों में हुए सुधारों की वजह से, हमारा सुझाव है कि आप TLS-बाहरी फ़ॉलबैक की कोशिश न करें. इसके बजाय, हमारा सुझाव है कि आप TLS वर्शन की बातचीत पर भरोसा करें.
  • ChaCha20-Poly1305, ChaCha20/Poly1305/NoPadding का दूसरा नाम है.
  • आखिर में बिंदु वाले होस्टनेम को एसएनआई होस्टनेम के तौर पर मान्य नहीं माना जाता.
  • सर्टिफ़िकेट के जवाबों के लिए साइनिंग पासकोड चुनते समय, CertificateRequest में मौजूद supported_signature_algorithms एक्सटेंशन का इस्तेमाल किया जाता है.
  • Android कीस्टोर जैसी ओपेक साइनिंग कुंजियों का इस्तेमाल, TLS में आरएसए-पीएसएस हस्ताक्षरों के साथ किया जा सकता है.

एचटीटीपीएस कनेक्शन में हुए बदलाव

अगर Android 10 पर चलने वाला कोई ऐप्लिकेशन, setSSLSocketFactory() में कोई वैल्यू नहीं डालता है, तो IllegalArgumentException गड़बड़ी दिखती है. पिछले वर्शन में, setSSLSocketFactory() में null पास करने का असर, मौजूदा डिफ़ॉल्ट फ़ैक्ट्री को पास करने जैसा ही होता था.

Android 11

एसएसएल सॉकेट, डिफ़ॉल्ट रूप से Conscrypt एसएसएल इंजन का इस्तेमाल करते हैं

Android का डिफ़ॉल्ट SSLSocket, Conscrypt पर आधारित है. Android 11 के बाद, यह सुविधा Conscrypt के SSLEngine के ऊपर अंदरूनी तौर पर बनाई गई है.