नेटवर्क सिक्योरिटी कॉन्फ़िगरेशन

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

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

नेटवर्क सुरक्षा कॉन्फ़िगरेशन फ़ाइल जोड़ना

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

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

भरोसेमंद सीए को पसंद के मुताबिक बनाना

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

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

डिफ़ॉल्ट रूप से, सभी ऐप्लिकेशन के सुरक्षित कनेक्शन (टीएलएस और एचटीटीपीएस जैसे प्रोटोकॉल का इस्तेमाल करके), पहले से इंस्टॉल किए गए सिस्टम सीए पर भरोसा करते हैं. साथ ही, Android 6.0 (एपीआई लेवल 23) और इससे कम वर्शन को टारगेट करने वाले ऐप्लिकेशन भी, डिफ़ॉल्ट रूप से उपयोगकर्ता के जोड़े गए सीए स्टोर पर भरोसा करते हैं. base-config (पूरे ऐप्लिकेशन के लिए) या domain-config (हर डोमेन के लिए) का इस्तेमाल करके, ऐप्लिकेशन के कनेक्शन को पसंद के मुताबिक बनाया जा सकता है.

कस्टम सीए कॉन्फ़िगर करना

ध्यान दें: सर्टिफ़िकेट की पारदर्शिता की पुष्टि, उन कनेक्शन पर नहीं की जाती जो कस्टम ट्रस्ट ऐंकर का इस्तेमाल करते हैं.

ऐसा हो सकता है कि आपको किसी ऐसे होस्ट से कनेक्ट करना हो जो खुद के हस्ताक्षर किए गए एसएसएल सर्टिफ़िकेट का इस्तेमाल करता है. इसके अलावा, आपको किसी ऐसे होस्ट से कनेक्ट करना पड़ सकता है जिसका एसएसएल सर्टिफ़िकेट, किसी ऐसी सीए (सर्टिफ़िकेट अथॉरिटी) ने जारी किया हो जो सार्वजनिक नहीं है. हालांकि, आपको उस सीए पर भरोसा है. जैसे, आपकी कंपनी की इंटरनल सीए. यहां दिए गए कोड के अंश में, res/xml/network_security_config.xml में कस्टम सीए (सर्टिफ़िकेट देने वाली संस्था) के लिए अपने ऐप्लिकेशन को कॉन्फ़िगर करने का तरीका बताया गया है: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

PEM या DER फ़ॉर्मैट में, खुद के हस्ताक्षर वाला या नॉन-पब्लिक सीए सर्टिफ़िकेट, res/raw/my_ca में जोड़ें.

भरोसेमंद सीए के सेट को सीमित करें

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

भरोसेमंद CA के सेट को सीमित करने का कॉन्फ़िगरेशन, किसी खास डोमेन के लिए कस्टम CA पर भरोसा करने जैसा ही होता है. हालांकि, इसमें अंतर यह है कि संसाधन में एक से ज़्यादा CA दिए जाते हैं. यहां दिए गए कोड के स्निपेट में, res/xml/network_security_config.xml में अपने ऐप्लिकेशन के भरोसेमंद सीए के सेट को सीमित करने का तरीका बताया गया है: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <domain includeSubdomains="true">cdn.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/trusted_roots"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

भरोसेमंद CA को PEM या DER फ़ॉर्मैट में res/raw/trusted_roots में जोड़ें. ध्यान दें कि अगर PEM फ़ॉर्मैट का इस्तेमाल किया जाता है, तो फ़ाइल में सिर्फ़ PEM डेटा होना चाहिए. इसमें कोई अतिरिक्त टेक्स्ट नहीं होना चाहिए. एक के बजाय, एक से ज़्यादा <certificates> एलिमेंट भी दिए जा सकते हैं.

अन्य CA पर भरोसा करना

ऐसा हो सकता है कि आपको अपने ऐप्लिकेशन के लिए, सिस्टम के भरोसेमंद सीए के अलावा अन्य सीए पर भरोसा करना हो. जैसे, अगर सिस्टम में सीए शामिल नहीं है या सीए, Android सिस्टम में शामिल होने की ज़रूरी शर्तों को पूरा नहीं करता है. res/xml/network_security_config.xml में किसी कॉन्फ़िगरेशन के लिए, एक से ज़्यादा सर्टिफ़िकेट सोर्स तय किए जा सकते हैं. इसके लिए, यहां दिए गए कोड के स्निपेट जैसा कोड इस्तेमाल करें. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="@raw/extracas"/>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

डीबग करने के लिए सीए कॉन्फ़िगर करना

एचटीटीपीएस से कनेक्ट होने वाले किसी ऐप्लिकेशन को डीबग करते समय, आपको ऐसे लोकल डेवलपमेंट सर्वर से कनेक्ट करना पड़ सकता है जिसमें आपके प्रोडक्शन सर्वर के लिए एसएसएल सर्टिफ़िकेट नहीं है. अपने ऐप्लिकेशन के कोड में कोई बदलाव किए बिना इस सुविधा का इस्तेमाल करने के लिए, सिर्फ़ डीबग करने के लिए इस्तेमाल किए जाने वाले सीए तय किए जा सकते हैं. इन पर सिर्फ़ तब भरोसा किया जाता है, जब android:debuggable true हो. इसके लिए, debug-overrides का इस्तेमाल करें. आम तौर पर, आईडीई और बिल्ड टूल, रिलीज़ नहीं किए गए बिल्ड के लिए इस फ़्लैग को अपने-आप सेट कर देते हैं.

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

नीचे दिए गए अंश में, res/xml/network_security_config.xml में सिर्फ़ डीबग करने के लिए सीए तय करने का तरीका बताया गया है:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

प्रमाणपत्र पारदर्शिता

ध्यान दें: सर्टिफ़िकेट ट्रांसपैरेंसी की सुविधा सिर्फ़ Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन पर उपलब्ध है.

प्रमाणपत्र पारदर्शिता (सीटी, RFC 6962) एक इंटरनेट स्टैंडर्ड है. इसे डिजिटल सर्टिफ़िकेट की सुरक्षा को बेहतर बनाने के लिए डिज़ाइन किया गया है. इसके तहत, सीए को जारी किए गए सभी सर्टिफ़िकेट, सार्वजनिक लॉग में सबमिट करने होते हैं. इससे सर्टिफ़िकेट जारी करने की प्रोसेस में पारदर्शिता और जवाबदेही बढ़ती है.

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

सर्टिफ़िकेट ट्रांसपेरेंसी का डिफ़ॉल्ट तरीका, एपीआई लेवल पर निर्भर करता है:

सर्टिफ़िकेट ट्रांसपैरेंसी से ऑप्ट आउट करना

ध्यान दें: Android 16 (एपीआई लेवल 36) के लिए, सर्टिफ़िकेट ट्रांसपैरेंसी में ऑप्ट इन करने के लिए, <certificateTransparency enabled="true"/> सेट करें. यह डिफ़ॉल्ट रूप से बंद होता है.

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

उदाहरण के लिए, ऐसा हो सकता है कि आपको अपने ऐप्लिकेशन को secure.example.com से कनेक्ट करने की अनुमति देनी हो. इसके लिए, आपको सर्टिफ़िकेट ट्रांसपैरेंसी की ज़रूरत न हो. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <certificateTransparency enabled="false"/>
    </domain-config>
</network-security-config>

Client Hello मैसेज को एन्क्रिप्ट (सुरक्षित) किया गया

ध्यान दें: एन्क्रिप्ट (सुरक्षित) किए गए क्लाइंट हैलो की सुविधा सिर्फ़ Android 17 (एपीआई लेवल 37) से उपलब्ध है. इसके लिए, ऐप्लिकेशन की नेटवर्किंग लाइब्रेरी में ECH की सुविधा होनी चाहिए. यहां दिया गया कॉन्फ़िगरेशन सिर्फ़ तब लागू होगा, जब नेटवर्किंग लाइब्रेरी ने ईसीएच को अपनाया हो.

Encrypted Client Hello (ECH, RFC 9849), TLS प्रोटोकॉल का एक एक्सटेंशन है. इसे सुरक्षित कनेक्शन की निजता को बेहतर बनाने के लिए डिज़ाइन किया गया है. यह टीएलएस हैंडशेक के संवेदनशील हिस्सों को एन्क्रिप्ट (सुरक्षित) करता है. इनमें सबसे अहम है सर्वर नेम इंडिकेशन (एसएनआई) फ़ील्ड.

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

एन्क्रिप्ट किए गए क्लाइंट हैलो के डिफ़ॉल्ट व्यवहार के बारे में यहां बताया गया है. यह एपीआई लेवल पर निर्भर करता है:

Encrypted ClientHello की सुविधा से ऑप्ट आउट करना

इस सुविधा को बंद करके, इससे ऑप्ट आउट किया जा सकता है. उदाहरण के लिए, अगर आपको सिर्फ़ disable-ech.example.com से कनेक्ट करते समय ECH बंद करना है, लेकिन अन्य सभी डोमेन के लिए ECH चालू रखना है, तो इस कॉन्फ़िगरेशन का इस्तेमाल करें: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <domainEncryption mode="enabled"/>
    </base-config>
    <domain-config>
        <domain includeSubdomains="true">disable-ech.example.com</domain>
        <domainEncryption mode="disabled"/>
    </domain-config>
</network-security-config>

क्लियरटेक्स्ट ट्रैफ़िक

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

क्लियरटेक्स्ट ट्रैफ़िक का डिफ़ॉल्ट तरीका, एपीआई लेवल पर निर्भर करता है:

  • Android 8.1 (एपीआई लेवल 27) तक, क्लियरटेक्स्ट की सुविधा डिफ़ॉल्ट रूप से चालू होती है. ऐप्लिकेशन, अतिरिक्त सुरक्षा के लिए क्लियरटेक्स्ट ट्रैफ़िक से ऑप्ट आउट कर सकते हैं.
  • Android 9 (एपीआई लेवल 28) से, क्लियरटेक्स्ट के लिए सहायता डिफ़ॉल्ट रूप से बंद होती है. जिन ऐप्लिकेशन को cleartext ट्रैफ़िक की ज़रूरत होती है वे cleartext ट्रैफ़िक के लिए ऑप्ट इन कर सकते हैं.

बिना एन्क्रिप्ट (सुरक्षित) किए गए ट्रैफ़िक से ऑप्ट आउट करना

ध्यान दें: इस सेक्शन में दिए गए दिशा-निर्देश, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो Android 8.1 (एपीआई लेवल 27) या इससे पहले के वर्शन को टारगेट करते हैं.

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

उदाहरण के लिए, हो सकता है कि आपको अपने ऐप्लिकेशन के लिए यह पक्का करना हो कि secure.example.com से कनेक्शन हमेशा एचटीटीपीएस पर किए जाएं, ताकि संवेदनशील ट्रैफ़िक को नुकसान पहुंचाने वाले नेटवर्क से सुरक्षित रखा जा सके. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">secure.example.com</domain>
    </domain-config>
</network-security-config>

बिना एन्क्रिप्ट (सुरक्षित) किए गए ट्रैफ़िक के लिए ऑप्ट इन करना

ध्यान दें: इस सेक्शन में दिए गए दिशा-निर्देश, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो Android 9 (एपीआई लेवल 28) या इसके बाद के वर्शन को टारगेट करते हैं.

अगर आपके ऐप्लिकेशन को क्लियरटेक्स्ट ट्रैफ़िक (एचटीटीपी) का इस्तेमाल करके डेस्टिनेशन से कनेक्ट करना है, तो उन डेस्टिनेशन के लिए क्लियरटेक्स्ट का इस्तेमाल करने का विकल्प चुना जा सकता है.

उदाहरण के लिए, हो सकता है कि आपको अपने ऐप्लिकेशन को insecure.example.com से असुरक्षित कनेक्शन बनाने की अनुमति देनी हो. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
    </domain-config>
</network-security-config>

अगर आपके ऐप्लिकेशन को किसी डोमेन के लिए cleartext ट्रैफ़िक में ऑप्ट इन करना है, तो cleartextTrafficPermitted="true" में base-config सेट करें. ध्यान दें कि जहां तक हो सके, इस असुरक्षित कॉन्फ़िगरेशन का इस्तेमाल नहीं करना चाहिए. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
    </base-config>
</network-security-config>

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

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

सर्टिफ़िकेट पिनिंग के लिए, सार्वजनिक कुंजी (X.509 सर्टिफ़िकेट का SubjectPublicKeyInfo) के हैश के हिसाब से सर्टिफ़िकेट का सेट दिया जाता है. इसके बाद, सर्टिफ़िकेट चेन को सिर्फ़ तब मान्य माना जाता है, जब उसमें पिन की गई कम से कम एक सार्वजनिक कुंजी शामिल हो.

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

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

यहां दिए गए स्निपेट में, res/xml/network_security_config.xml में सर्टिफ़िकेट पिन करने का तरीका बताया गया है: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

कॉन्फ़िगरेशन इनहेरिटेंस का तरीका

किसी कॉन्फ़िगरेशन में सेट नहीं की गई वैल्यू इनहेरिट की जाती हैं. इस व्यवहार की वजह से, कॉन्फ़िगरेशन फ़ाइल को पढ़ने में आसानी होती है. साथ ही, ज़्यादा जटिल कॉन्फ़िगरेशन भी किए जा सकते हैं.

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

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

नीचे दिया गया अंश दिखाता है कि res/xml/network_security_config.xml में नेस्टिंग कैसी दिखेगी:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <domain-config cleartextTrafficPermitted="false">
            <domain includeSubdomains="true">secure.example.com</domain>
        </domain-config>
    </domain-config>
</network-security-config>

लोकलहोस्ट कॉन्फ़िगरेशन

आम तौर पर, लोकल होस्ट कनेक्शन के लिए नेटवर्क सुरक्षा सुविधाओं को लागू करना ज़रूरी नहीं होता. उदाहरण के लिए, लोकल होस्ट कनेक्शन के लिए सर्टिफ़िकेट ट्रांसपेरंसी की ज़रूरत बहुत कम पड़ती है.

Android 17 (एपीआई लेवल 37) और इसके बाद के वर्शन में, अगर लोकल होस्ट के लिए कोई कॉन्फ़िगरेशन तय नहीं किया गया है, तो एक इंप्लिसिट कॉन्फ़िगरेशन शामिल किया जाता है. डिफ़ॉल्ट रूप से, यह कॉन्फ़िगरेशन ये काम करता है:

  • इससे क्लियरटेक्स्ट ट्रैफ़िक की अनुमति मिलती है.
  • यह सर्टिफ़िकेट ट्रांसपैरेंसी (सीटी) लागू नहीं करता.
  • सर्टिफ़िकेट पिन करने की सुविधा लागू नहीं करता.
  • ट्रस्ट ऐंकर के लिए, <base-config> को डेलिगेट करता है.

किसी कॉन्फ़िगरेशन को लोकल होस्ट को टारगेट करने वाला तब माना जाता है, जब डोमेन:

  • localhost
  • ip6-localhost या
  • न्यूमेरिकल आईपी पता और InetAddress.isLoopback(), true है (उदाहरण के लिए, 127.0.0.1 या [::1])

कॉन्फ़िगरेशन फ़ाइल का फ़ॉर्मैट

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

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </base-config>

    <domain-config>
        <domain>android.com</domain>
        ...
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
        <pin-set>
            <pin digest="...">...</pin>
            ...
        </pin-set>
    </domain-config>
    ...
    <debug-overrides>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </debug-overrides>
</network-security-config>

यहां दिए गए सेक्शन में, फ़ाइल फ़ॉर्मैट के सिंटैक्स और अन्य जानकारी के बारे में बताया गया है.

<network-security-config>

इसमें ये शामिल हो सकते हैं:
<base-config>
में से 0 या 1 <domain-config>
में से कोई भी संख्या <debug-overrides> में से 0 या 1

<base-config>

सिंटैक्स:
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
इसमें ये शामिल हो सकते हैं:
<trust-anchors> <certificateTransparency> <domainEncryption>
विवरण:
यह डिफ़ॉल्ट कॉन्फ़िगरेशन, उन सभी कनेक्शन के लिए इस्तेमाल किया जाता है जिनके डेस्टिनेशन को domain-config में शामिल नहीं किया गया है.

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

Android 9 (एपीआई लेवल 28) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन इस तरह है: 

<base-config cleartextTrafficPermitted="false">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

Android 7.0 (एपीआई लेवल 24) से लेकर Android 8.1 (एपीआई लेवल 27) को टारगेट करने वाले ऐप्लिकेशन के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन इस तरह है: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

Android 6.0 (एपीआई लेवल 23) और इससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन इस तरह है: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

<domain-config>

सिंटैक्स:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
इसमें ये शामिल हो सकते हैं:
1 या इससे ज़्यादा <domain>
0 या 1 <certificateTransparency>
0 या 1 <trust-anchors>
0 या 1 <pin-set>
0 या 1 <domainEncryption>
नेस्ट किए गए किसी भी नंबर <domain-config>
विवरण:
यह कॉन्फ़िगरेशन, खास डेस्टिनेशन से कनेक्शन के लिए इस्तेमाल किया जाता है. इसे domain एलिमेंट तय करते हैं.

ध्यान दें कि अगर कई domain-config एलिमेंट किसी डेस्टिनेशन को कवर करते हैं, तो सबसे सटीक (सबसे लंबा) मैचिंग डोमेन नियम वाला कॉन्फ़िगरेशन इस्तेमाल किया जाता है.

<domain>

सिंटैक्स:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
एट्रिब्यूट:
includeSubdomains
अगर "true" है, तो डोमेन से जुड़ा यह नियम, डोमेन और सभी सबडोमेन से मेल खाता है. इसमें सबडोमेन के सबडोमेन भी शामिल हैं. इसके अलावा, यह नियम सिर्फ़ पूरी तरह मैच होने वाले शब्दों पर लागू होता है.

<certificateTransparency>

सिंटैक्स:
<certificateTransparency enabled=["true" | "false"]/>
विवरण:
अगर true है, तो ऐप्लिकेशन, सर्टिफ़िकेट की पुष्टि करने के लिए प्रमाणपत्र पारदर्शिता लॉग का इस्तेमाल करेगा. जब कोई ऐप्लिकेशन अपने सर्टिफ़िकेट (या उपयोगकर्ता स्टोर) का इस्तेमाल करता है, तो ऐसा हो सकता है कि वह सर्टिफ़िकेट सार्वजनिक न हो. इसलिए, प्रमाणपत्र पारदर्शिता का इस्तेमाल करके उसकी पुष्टि नहीं की जा सकती. डिफ़ॉल्ट रूप से, इन मामलों में पुष्टि करने की सुविधा बंद होती है. डोमेन कॉन्फ़िगरेशन में <certificateTransparency enabled="true"/> का इस्तेमाल करके, पुष्टि करने की प्रोसेस को अब भी पूरा किया जा सकता है. हर <domain-config> के लिए, आकलन इस क्रम में किया जाता है:
  1. अगर certificateTransparency चालू है, तो पुष्टि करने की सुविधा चालू करें.
  2. अगर कोई <trust-anchors>, "user" या इनलाइन (यानी, "@raw/cert.pem") पर जाकर, पुष्टि करने की सुविधा बंद करें.
  3. इसके अलावा, इनहेरिट किए गए कॉन्फ़िगरेशन का इस्तेमाल करें.

<domainEncryption>

सिंटैक्स:
<domainEncryption mode=["enabled" | "disabled"]/>
विवरण:
यह कुकी, बताए गए डोमेन से कनेक्शन के लिए, Encrypted Client Hello (ECH) के व्यवहार को कंट्रोल करती है.

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

mode एट्रिब्यूट की वैल्यू इनमें से कोई एक हो सकती है:

  • enabled: टीएलएस हैंडशेक सेट अप करते समय, ईसीएच कॉन्फ़िगरेशन उपलब्ध होने पर, कनेक्शन पर ईसीएच लागू करता है. साथ ही, ईसीएच ग्रीस को चालू करता है.
  • disabled: किसी भी कनेक्शन पर ECH या ECH GREASE का इस्तेमाल करने की कोशिश न करें.

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

<debug-overrides>

सिंटैक्स:
<debug-overrides>
    ...
</debug-overrides>
इसमें ये शामिल हो सकते हैं:
0 या 1 <trust-anchors>
विवरण:
android:debuggable "true" होने पर लागू किए जाने वाले ओवरराइड. आम तौर पर, ऐसा आईडीई और बिल्ड टूल से जनरेट किए गए नॉन-रिलीज़ बिल्ड के लिए होता है. debug-overrides में बताए गए ट्रस्ट ऐंकर, अन्य सभी कॉन्फ़िगरेशन में जोड़े जाते हैं. साथ ही, जब सर्वर का सर्टिफ़िकेट चेन, सिर्फ़ डीबग करने के लिए इस्तेमाल किए जाने वाले इनमें से किसी एक ट्रस्ट ऐंकर का इस्तेमाल करता है, तब सर्टिफ़िकेट पिनिंग नहीं की जाती है. अगर android:debuggable को "false" पर सेट किया गया है, तो इस सेक्शन को पूरी तरह से अनदेखा कर दिया जाता है.

<trust-anchors>

सिंटैक्स:
<trust-anchors>
...
</trust-anchors>
इसमें ये शामिल हो सकते हैं:
<certificates> की कोई भी संख्या
विवरण:
सुरक्षित कनेक्शन के लिए, भरोसेमंद ऐंकर का सेट.

<certificates>

सिंटैक्स:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
विवरण:
trust-anchors एलिमेंट के लिए X.509 सर्टिफ़िकेट का सेट.
एट्रिब्यूट:
src
CA सर्टिफ़िकेट का सोर्स. हर सर्टिफ़िकेट इनमें से कोई एक हो सकता है:
  • एक रॉ रिसॉर्स आईडी, जो X.509 सर्टिफ़िकेट वाली फ़ाइल की ओर ले जाता है. सर्टिफ़िकेट, DER या PEM फ़ॉर्मैट में एन्कोड किए गए होने चाहिए. PEM सर्टिफ़िकेट के मामले में, फ़ाइल में PEM के अलावा अन्य डेटा नहीं होना चाहिए. जैसे, टिप्पणियां.
  • "system" पहले से इंस्टॉल किए गए सिस्टम CA सर्टिफ़िकेट के लिए
  • "user" उपयोगकर्ता के जोड़े गए CA सर्टिफ़िकेट के लिए
overridePins

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

डिफ़ॉल्ट वैल्यू "false" होती है. हालांकि, अगर इसे debug-overrides एलिमेंट में तय किया गया है, तो डिफ़ॉल्ट वैल्यू "true" होती है.

<pin-set>

सिंटैक्स:
<pin-set expiration="date">
...
</pin-set>
इसमें ये शामिल हो सकते हैं:
<pin> की कोई भी संख्या
विवरण:
सार्वजनिक पासकोड पिन का सेट. सुरक्षित कनेक्शन को भरोसेमंद बनाने के लिए, भरोसे की चेन में मौजूद सार्वजनिक कुंजियों में से किसी एक का पिन के सेट में होना ज़रूरी है. पिन के फ़ॉर्मैट के बारे में जानने के लिए, <pin> पर जाएं.
एट्रिब्यूट:
expiration
yyyy-MM-dd फ़ॉर्मैट में वह तारीख जिस दिन पिन की समयसीमा खत्म हो जाती है. इससे पिन करने की सुविधा बंद हो जाती है. अगर एट्रिब्यूट सेट नहीं किया जाता है, तो पिन की समयसीमा खत्म नहीं होती है.

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

<pin>

सिंटैक्स:
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
एट्रिब्यूट:
digest
पिन जनरेट करने के लिए इस्तेमाल किया गया डाइजेस्ट एल्गोरिदम. फ़िलहाल, सिर्फ़ "SHA-256" का इस्तेमाल किया जा सकता है.