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

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

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

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

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

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

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

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

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

डिफ़ॉल्ट रूप से, सभी ऐप्लिकेशन के सुरक्षित कनेक्शन (TLS और एचटीटीपीएस जैसे प्रोटोकॉल का इस्तेमाल करके), पहले से इंस्टॉल किए गए सिस्टम सीए पर भरोसा करते हैं. साथ ही, 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>

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

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

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

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

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

अन्य सीए पर भरोसा करना

हो सकता है कि आप अपने ऐप्लिकेशन को उन अन्य सीए पर भरोसा करने के लिए कहें जिन पर सिस्टम भरोसा नहीं करता. जैसे, अगर सिस्टम में अब तक सीए शामिल नहीं है या सीए, 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>

सर्टिफ़िकेट पारदर्शिता के लिए ऑप्ट इन करना

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

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

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

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

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

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

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

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

<?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>

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

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

सर्टिफ़िकेट पिन करने के लिए, सार्वजनिक कुंजी (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 से लिया जाता है. अगर नेस्ट नहीं किया गया है, तो उन्हें base-config से लिया जाता है. base-config में सेट नहीं की गई वैल्यू के लिए, प्लैटफ़ॉर्म की डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है.

उदाहरण के लिए, मान लें कि example.com के सबडोमेन से जुड़े सभी कनेक्शन के लिए, सीए के कस्टम सेट का इस्तेमाल करना ज़रूरी है. इसके अलावा, secure.example.com से कनेक्ट करते समय इसके अलावा, इन डोमेन पर क्लियरटेक्स्ट ट्रैफ़िक की अनुमति है. example.com के कॉन्फ़िगरेशन में secure.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>
जानकारी:
यह डिफ़ॉल्ट कॉन्फ़िगरेशन उन सभी कनेक्शन के लिए इस्तेमाल किया जाता है जिनके डेस्टिनेशन पर 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>
इसमें ये चीज़ें शामिल हो सकती हैं:
एक या उससे ज़्यादा <domain>
शून्य या एक <certificateTransparency>
शून्य या एक <trust-anchors>
शून्य या एक <pin-set>
नेस्ट किए गए <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. इसके अलावा, इनहेरिट किए गए कॉन्फ़िगरेशन का इस्तेमाल करें.

<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
सीए सर्टिफ़िकेट का सोर्स. हर सर्टिफ़िकेट इनमें से कोई एक हो सकता है:
  • X.509 सर्टिफ़िकेट वाली फ़ाइल पर ले जाने वाला रॉ रिसॉर्स आईडी. सर्टिफ़िकेट, DER या PEM फ़ॉर्मैट में एन्कोड होने चाहिए. PEM सर्टिफ़िकेट के मामले में, फ़ाइल में टिप्पणियों जैसे अतिरिक्त नॉन-पीएम डेटा नहीं होना चाहिए.
  • "system" पहले से इंस्टॉल किए गए सिस्टम के CA सर्टिफ़िकेट के लिए
  • उपयोगकर्ता के जोड़े गए सीए सर्टिफ़िकेट के लिए "user"
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" का इस्तेमाल किया जा सकता है.

अन्य संसाधन

नेटवर्क सुरक्षा कॉन्फ़िगरेशन के बारे में ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें.

कोडलैब