নেটওয়ার্ক নিরাপত্তা কনফিগারেশন

নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য আপনাকে অ্যাপ কোড পরিবর্তন না করেই একটি নিরাপদ, ঘোষণামূলক কনফিগারেশন ফাইলে আপনার অ্যাপের নেটওয়ার্ক নিরাপত্তা সেটিংস কাস্টমাইজ করতে দেয়। এই সেটিংস নির্দিষ্ট ডোমেন এবং একটি নির্দিষ্ট অ্যাপের জন্য কনফিগার করা যেতে পারে। এই বৈশিষ্ট্যের মূল ক্ষমতা হল:

  • কাস্টম ট্রাস্ট অ্যাঙ্কর: একটি অ্যাপের সুরক্ষিত সংযোগের জন্য কোন সার্টিফিকেট অথরিটি (CA) বিশ্বস্ত তা কাস্টমাইজ করুন। উদাহরণস্বরূপ, নির্দিষ্ট স্ব-স্বাক্ষরিত শংসাপত্রগুলিতে বিশ্বাস করা বা অ্যাপটি বিশ্বাস করে এমন পাবলিক CA-এর সেটকে সীমাবদ্ধ করা৷
  • ডিবাগ-অনলি ওভাররাইড: ইনস্টল করা বেসে অতিরিক্ত ঝুঁকি ছাড়াই একটি অ্যাপে নিরাপদে সুরক্ষিত সংযোগ ডিবাগ করুন।
  • ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট: ক্লিয়ারটেক্সট (অএনক্রিপ্ট করা) ট্র্যাফিকের দুর্ঘটনাজনিত ব্যবহার থেকে অ্যাপগুলিকে রক্ষা করুন।
  • শংসাপত্র পিনিং: নির্দিষ্ট শংসাপত্রের সাথে একটি অ্যাপের সুরক্ষিত সংযোগ সীমাবদ্ধ করুন।

একটি নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল যোগ করুন

নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্যটি একটি XML ফাইল ব্যবহার করে যেখানে আপনি আপনার অ্যাপের জন্য সেটিংস নির্দিষ্ট করেন। এই ফাইলটি নির্দেশ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে একটি এন্ট্রি অন্তর্ভুক্ত করতে হবে৷ একটি ম্যানিফেস্ট থেকে নিম্নলিখিত কোড উদ্ধৃতি প্রদর্শন করে কিভাবে এই এন্ট্রি তৈরি করতে হয়: 

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

বিশ্বস্ত CA কাস্টমাইজ করুন

আপনি প্ল্যাটফর্ম ডিফল্টের পরিবর্তে আপনার অ্যাপটি CA-এর একটি কাস্টম সেট বিশ্বাস করতে চাইতে পারেন। এর জন্য সবচেয়ে সাধারণ কারণগুলি হল:

  • একটি কাস্টম CA সহ একটি হোস্টের সাথে সংযোগ করা, যেমন একটি CA যা স্ব-স্বাক্ষরিত বা একটি কোম্পানির মধ্যে অভ্যন্তরীণভাবে জারি করা হয়৷
  • প্রতিটি প্রি-ইনস্টল করা CA-এর পরিবর্তে শুধুমাত্র আপনার বিশ্বাসযোগ্য CA-এর মধ্যে CA-এর সেট সীমাবদ্ধ করা।
  • সিস্টেমে অন্তর্ভুক্ত নয় অতিরিক্ত CA-কে বিশ্বাস করা।

ডিফল্টরূপে, সমস্ত অ্যাপ থেকে সুরক্ষিত সংযোগগুলি (TLS এবং HTTPS-এর মতো প্রোটোকল ব্যবহার করে) আগে থেকে ইনস্টল করা সিস্টেম CA-কে বিশ্বাস করে এবং Android 6.0 (API লেভেল 23) এবং নিম্নতর অ্যাপ্লিকেশানগুলিকে লক্ষ্য করে ডিফল্টভাবে ব্যবহারকারী-যুক্ত CA স্টোরকেও বিশ্বাস করে৷ আপনি base-config (অ্যাপ-ওয়াইড কাস্টমাইজেশনের জন্য) বা domain-config (প্রতি-ডোমেন কাস্টমাইজেশনের জন্য) ব্যবহার করে আপনার অ্যাপের সংযোগগুলি কাস্টমাইজ করতে পারেন।

একটি কাস্টম CA কনফিগার করুন

আপনি এমন একটি হোস্টের সাথে সংযোগ করতে চাইতে পারেন যা একটি স্ব-স্বাক্ষরিত SSL শংসাপত্র ব্যবহার করে বা এমন একটি হোস্টের সাথে যার SSL শংসাপত্র একটি অ-পাবলিক CA দ্বারা জারি করা হয় যা আপনি বিশ্বাস করেন, যেমন আপনার কোম্পানির অভ্যন্তরীণ CA৷ নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml এ একটি কাস্টম CA-এর জন্য কীভাবে আপনার অ্যাপ কনফিগার করবেন তা প্রদর্শন করে:

<?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 ফর্ম্যাটে স্ব-স্বাক্ষরিত বা অ-সর্বজনীন CA শংসাপত্র যোগ করুন।

বিশ্বস্ত CA-এর সেট সীমিত করুন

আপনি যদি না চান যে আপনার অ্যাপ সিস্টেমের দ্বারা বিশ্বস্ত সমস্ত CA-কে বিশ্বাস করুক, আপনি পরিবর্তে বিশ্বাস করার জন্য CA-এর একটি কম সেট নির্দিষ্ট করতে পারেন। এটি অন্য যেকোন CA দ্বারা জারি করা প্রতারণামূলক শংসাপত্র থেকে অ্যাপটিকে রক্ষা করে৷

বিশ্বস্ত CA-এর সেট সীমিত করার কনফিগারেশন একটি নির্দিষ্ট ডোমেনের জন্য একটি কাস্টম CA-কে বিশ্বাস করার অনুরূপ, রিসোর্সে একাধিক CA প্রদান করা ছাড়া। নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml এ আপনার অ্যাপের বিশ্বস্ত CA-এর সেটকে কীভাবে সীমাবদ্ধ করতে হয় তা প্রদর্শন করে:

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

res/raw/trusted_roots এ PEM বা DER ফর্ম্যাটে বিশ্বস্ত CA যোগ করুন। মনে রাখবেন যে আপনি যদি PEM ফর্ম্যাট ব্যবহার করেন তবে ফাইলটিতে শুধুমাত্র PEM ডেটা থাকতে হবে এবং কোনও অতিরিক্ত পাঠ্য থাকবে না। আপনি একটির পরিবর্তে একাধিক <certificates> উপাদান প্রদান করতে পারেন।

অতিরিক্ত CA-কে বিশ্বাস করুন

আপনি আপনার অ্যাপটিকে অতিরিক্ত CA-কে বিশ্বাস করতে চাইতে পারেন যেগুলি সিস্টেমের দ্বারা বিশ্বাসযোগ্য নয়, যেমন যদি সিস্টেমটি এখনও CA অন্তর্ভুক্ত না করে বা 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>

ডিবাগিংয়ের জন্য CA কনফিগার করুন

HTTPS-এর মাধ্যমে সংযোগকারী একটি অ্যাপ ডিবাগ করার সময়, আপনি একটি স্থানীয় ডেভেলপমেন্ট সার্ভারের সাথে সংযোগ করতে চাইতে পারেন যেখানে আপনার উৎপাদন সার্ভারের জন্য SSL শংসাপত্র নেই। আপনার অ্যাপের কোডে কোনো পরিবর্তন না করেই এটিকে সমর্থন করতে, আপনি debug-overrides ব্যবহার করে শুধুমাত্র ডিবাগ-অনলি CAগুলি নির্দিষ্ট করতে পারেন, যেগুলি শুধুমাত্র তখনই বিশ্বস্ত হয় যখন android:debuggable true হয়। সাধারণত, IDEs এবং বিল্ড টুলগুলি এই পতাকাটি অ-মুক্তি বিল্ডগুলির জন্য স্বয়ংক্রিয়ভাবে সেট করে।

এটি সাধারণ শর্তসাপেক্ষ কোডের চেয়ে নিরাপদ কারণ নিরাপত্তা সতর্কতা হিসাবে, অ্যাপ স্টোরগুলি ডিবাগযোগ্য হিসাবে চিহ্নিত অ্যাপগুলিকে গ্রহণ করে না৷

নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml এ ডিবাগ-শুধুমাত্র CAগুলি নির্দিষ্ট করতে হয়: 

<?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 8.1 (API স্তর 27) বা তার নিচের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়।

আপনি যদি আপনার অ্যাপটি শুধুমাত্র সুরক্ষিত সংযোগ ব্যবহার করে গন্তব্যগুলির সাথে সংযোগ করতে চান, তাহলে আপনি সেই গন্তব্যগুলিতে সমর্থনকারী ক্লিয়ারটেক্সট (HTTPS এর পরিবর্তে এনক্রিপ্ট করা HTTP প্রোটোকল ব্যবহার করে) অপ্ট আউট করতে পারেন৷ এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উত্স দ্বারা প্রদত্ত URL গুলির পরিবর্তনের কারণে অ্যাপগুলিতে দুর্ঘটনাজনিত রিগ্রেশন প্রতিরোধ করতে সহায়তা করে৷ আরও বিস্তারিত জানার জন্য NetworkSecurityPolicy.isCleartextTrafficPermitted() দেখুন।

উদাহরণ স্বরূপ, আপনি আপনার অ্যাপটি নিশ্চিত করতে চাইতে পারেন যে secure.example.com এর সাথে সংযোগগুলি সর্বদা HTTPS-এর মাধ্যমে প্রতিকূল নেটওয়ার্কগুলি থেকে সংবেদনশীল ট্র্যাফিককে সুরক্ষিত করতে হবে৷

নীচের উদ্ধৃতিটি দেখায় কিভাবে 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>

পিন সার্টিফিকেট

সাধারণত, একটি অ্যাপ সমস্ত প্রাক-ইনস্টল করা CAগুলিকে বিশ্বাস করে৷ যদি এই CA-এর মধ্যে কেউ একটি জালিয়াতি শংসাপত্র জারি করে, তাহলে অ্যাপটি অন-পাথ আক্রমণকারীর থেকে ঝুঁকিতে থাকবে। কিছু অ্যাপ্লিকেশান তাদের বিশ্বাসযোগ্য CA-এর সেট সীমিত করে বা শংসাপত্র পিনিংয়ের মাধ্যমে তাদের গ্রহণযোগ্য শংসাপত্রের সেট সীমিত করতে বেছে নেয়।

সার্টিফিকেট পিনিং পাবলিক কী (X.509 সার্টিফিকেটের SubjectPublicKeyInfo ) হ্যাশের মাধ্যমে সার্টিফিকেটের একটি সেট প্রদান করে করা হয়। একটি শংসাপত্র চেইন তখনই বৈধ হয় যদি শংসাপত্রের চেইনে কমপক্ষে একটি পিন করা পাবলিক কী থাকে৷

মনে রাখবেন, শংসাপত্র পিনিং ব্যবহার করার সময়, আপনার সর্বদা একটি ব্যাকআপ কী অন্তর্ভুক্ত করা উচিত যাতে আপনি যদি নতুন কীগুলিতে স্যুইচ করতে বা CA পরিবর্তন করতে বাধ্য হন (যখন একটি CA শংসাপত্র বা সেই CA-এর মধ্যবর্তীতে পিন করা হয়), আপনার অ্যাপের সংযোগ প্রভাবিত না হয়৷ অন্যথায়, সংযোগ পুনরুদ্ধার করতে আপনাকে অবশ্যই অ্যাপে একটি আপডেট করতে হবে।

অতিরিক্তভাবে, পিনের জন্য মেয়াদ শেষ হওয়ার সময় সেট করা সম্ভব যার পরে পিন করা হয় না। এটি আপডেট করা হয়নি এমন অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে৷ যাইহোক, পিনগুলিতে একটি মেয়াদ শেষ হওয়ার সময় সেট করা আক্রমণকারীদের আপনার পিন করা শংসাপত্রগুলিকে বাইপাস করতে সক্ষম করতে পারে৷

নীচের অংশটি 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 এর সাবডোমেনের সমস্ত সংযোগ অবশ্যই CA-এর একটি কাস্টম সেট ব্যবহার করবে৷ অতিরিক্তভাবে, 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 ফাইল বিন্যাস ব্যবহার করে। ফাইলের সামগ্রিক গঠন নিম্নলিখিত কোড নমুনায় দেখানো হয়েছে:

<?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>
বর্ণনা:
সমস্ত সংযোগ দ্বারা ব্যবহৃত ডিফল্ট কনফিগারেশন যার গন্তব্য একটি domain-config দ্বারা আচ্ছাদিত নয়।

যে কোনো মান সেট করা নেই প্ল্যাটফর্ম ডিফল্ট মান ব্যবহার করে।

অ্যান্ড্রয়েড 9 (এপিআই স্তর 28) এবং উচ্চতরকে লক্ষ্য করা অ্যাপগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:

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

Android 7.0 (API লেভেল 24) থেকে Android 8.1 (API লেভেল 27) লক্ষ্য করা অ্যাপগুলির ডিফল্ট কনফিগারেশন নিম্নরূপ:

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

অ্যান্ড্রয়েড 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 <trust-anchors>
0 বা 1 <pin-set>
নেস্টেড <domain-config> এর যেকোনো সংখ্যা
বর্ণনা:
domain উপাদান দ্বারা সংজ্ঞায়িত নির্দিষ্ট গন্তব্যের সাথে সংযোগের জন্য ব্যবহৃত কনফিগারেশন।

মনে রাখবেন যে যদি একাধিক domain-config উপাদান একটি গন্তব্যকে কভার করে, তবে সবচেয়ে নির্দিষ্ট (দীর্ঘতম) মিলিত ডোমেন নিয়মের সাথে কনফিগারেশন ব্যবহার করা হয়।

<ডোমেইন>

সিনট্যাক্স:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
গুণাবলী:
includeSubdomains
যদি "true" , তাহলে এই ডোমেন নিয়মটি ডোমেন এবং সাবডোমেনের সাবডোমেন সহ সমস্ত সাবডোমেনের সাথে মেলে। অন্যথায়, নিয়ম শুধুমাত্র সঠিক মিলের ক্ষেত্রে প্রযোজ্য।

<debug-overrides>

সিনট্যাক্স:
<debug-overrides>
    ...
</debug-overrides>
থাকতে পারে:
0 বা 1 <trust-anchors>
বর্ণনা:
android:debuggable যখন "true" হয় তখন ওভাররাইড প্রয়োগ করা হয়, যা সাধারণত IDEs এবং বিল্ড টুলস দ্বারা উত্পন্ন নন-রিলিজ বিল্ডগুলির ক্ষেত্রে হয়৷ debug-overrides নির্দিষ্ট করা ট্রাস্ট অ্যাঙ্করগুলি অন্যান্য সমস্ত কনফিগারেশনে যোগ করা হয় এবং সার্ভারের শংসাপত্র চেইন যখন এই ডিবাগ-অনলি ট্রাস্ট অ্যাঙ্করগুলির মধ্যে একটি ব্যবহার করে তখন শংসাপত্র পিন করা হয় না। যদি android:debuggable হয় "false" , তাহলে এই বিভাগটিকে সম্পূর্ণরূপে উপেক্ষা করা হয়৷

<ট্রাস্ট-অ্যাঙ্করস>

সিনট্যাক্স:
<trust-anchors>
...
</trust-anchors>
থাকতে পারে:
যে কোন সংখ্যা <certificates>
বর্ণনা:
নিরাপদ সংযোগের জন্য বিশ্বস্ত অ্যাঙ্করগুলির সেট৷

<সার্টিফিকেট>

সিনট্যাক্স:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
বর্ণনা:
trust-anchors উপাদানগুলির জন্য X.509 শংসাপত্রের সেট।
গুণাবলী:
src
CA সার্টিফিকেটের উৎস। প্রতিটি শংসাপত্র নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
  • X.509 সার্টিফিকেট ধারণকারী একটি ফাইলের দিকে নির্দেশ করে একটি কাঁচা সম্পদ আইডি। শংসাপত্রগুলি DER বা PEM ফর্ম্যাটে এনকোড করা আবশ্যক৷ PEM শংসাপত্রের ক্ষেত্রে, ফাইলটিতে মন্তব্যের মতো অতিরিক্ত নন-PEM ডেটা থাকতে হবে না ।
  • প্রাক-ইনস্টল করা সিস্টেম CA সার্টিফিকেটের জন্য "system"
  • ব্যবহারকারী-সংযুক্ত CA শংসাপত্রের জন্য "user"
overridePins

যদি এই উৎস থেকে CA বাইপাস শংসাপত্র পিনিং হয় তা নির্দিষ্ট করে৷ যদি "true" , তাহলে শংসাপত্রের চেইনে পিনিং করা হয় না যা এই উৎস থেকে CA-এর একজন দ্বারা স্বাক্ষরিত। এটি CA ডিবাগ করার জন্য বা আপনার অ্যাপের নিরাপদ ট্র্যাফিকের ম্যান-ইন-দ্য-মিডল আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।

debug-overrides এলিমেন্টে নির্দিষ্ট করা না থাকলে ডিফল্ট "false" হয়, যে ক্ষেত্রে ডিফল্টটি "true" ।

<পিন-সেট>

সিনট্যাক্স:
<pin-set expiration="date">
...
</pin-set>
থাকতে পারে:
<pin> এর যেকোনো সংখ্যা
বর্ণনা:
পাবলিক কী পিনের একটি সেট। একটি নিরাপদ সংযোগ বিশ্বস্ত হওয়ার জন্য, বিশ্বাসের চেইনের সর্বজনীন কীগুলির মধ্যে একটি পিনের সেটে থাকা আবশ্যক৷ পিনের বিন্যাসের জন্য <pin> দেখুন।
গুণাবলী:
expiration
তারিখ, yyyy-MM-dd বিন্যাসে, যেটিতে পিনগুলির মেয়াদ শেষ হয়ে যায়, এইভাবে পিন করা অক্ষম করে৷ যদি অ্যাট্রিবিউট সেট করা না থাকে, তাহলে পিনের মেয়াদ শেষ হয় না।

মেয়াদ শেষ হওয়া অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে যেগুলি তাদের পিন সেটের আপডেট পায় না, যেমন ব্যবহারকারী যখন অ্যাপ আপডেটগুলি অক্ষম করে।

<পিন>

সিনট্যাক্স:
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
গুণাবলী:
digest
পিন তৈরি করতে ব্যবহৃত ডাইজেস্ট অ্যালগরিদম। বর্তমানে, শুধুমাত্র "SHA-256" সমর্থিত।

অতিরিক্ত সম্পদ

নেটওয়ার্ক নিরাপত্তা কনফিগারেশন সম্পর্কে আরও তথ্যের জন্য, নিম্নলিখিত সংস্থানগুলি দেখুন৷

কোডল্যাব