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

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

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

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

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

<?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 पर भरोसा करने जैसा ही होता है. हालांकि, इसमें अंतर यह है कि संसाधन में एक से ज़्यादा 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>

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

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

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

यहां दिए गए उदाहरण में, 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 की सीटी से जुड़ी नीति देखें.

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

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

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

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

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

ध्यान दें: इस सेक्शन में दिए गए दिशा-निर्देश, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो 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 से ली जाती हैं.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>

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

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

<?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>
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>
नेस्ट किए गए <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. इसके अलावा, इनहेरिट किए गए कॉन्फ़िगरेशन का इस्तेमाल करें.

<debug-overrides>

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

<trust-anchors>

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

<certificates>

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

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

डिफ़ॉल्ट वैल्यू "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" का इस्तेमाल किया जा सकता है.