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

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

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

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

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

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

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

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

  • कस्टम सीए वाले होस्ट से कनेक्ट करना. जैसे, ऐसा सीए जिस पर खुद के हस्ताक्षर किए गए हों या जिसे कंपनी के अंदरूनी तौर पर जारी किया गया हो.
  • पहले से इंस्टॉल किए गए हर 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 पर भरोसा करने जैसा ही होता है. हालांकि, इसमें संसाधन में एक से ज़्यादा 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) एक इंटरनेट स्टैंडर्ड है. इसे डिजिटल सर्टिफ़िकेट की सुरक्षा को बेहतर बनाने के लिए डिज़ाइन किया गया है. इसके तहत, CA को जारी किए गए सभी सर्टिफ़िकेट, सार्वजनिक लॉग में सबमिट करने होते हैं. इससे सर्टिफ़िकेट जारी करने की प्रोसेस में पारदर्शिता और जवाबदेही बढ़ती है.

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

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

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

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

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

डिफ़ॉल्ट रूप से, एन्क्रिप्ट (सुरक्षित) किए गए क्लाइंट हैलो का व्यवहार, एपीआई लेवल पर निर्भर करता है:

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>
description:
यह डिफ़ॉल्ट कॉन्फ़िगरेशन, उन सभी कनेक्शन के लिए इस्तेमाल किया जाता है जिनका डेस्टिनेशन 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>
description:
यह कॉन्फ़िगरेशन, domain एलिमेंट के ज़रिए तय किए गए खास डेस्टिनेशन से कनेक्शन के लिए इस्तेमाल किया जाता है.

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

<domain>

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

<certificateTransparency>

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

<domainEncryption>

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

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

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

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

अगर कोई वैल्यू तय नहीं की गई है, तो डिफ़ॉल्ट mode वैल्यू "opportunistic" होती है.

<debug-overrides>

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

<trust-anchors>

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

<certificates>

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

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

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

<pin-set>

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

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

<pin>

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