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

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

• কাস্টম ট্রাস্ট অ্যাঙ্কর: একটি অ্যাপের সুরক্ষিত সংযোগের জন্য কোন সার্টিফিকেট অথরিটি (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-গুলোর মধ্যে সীমাবদ্ধ রাখা।
• সিস্টেমে অন্তর্ভুক্ত নয় এমন অতিরিক্ত 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>

PEM বা DER ফরম্যাটে স্ব-স্বাক্ষরিত বা অপ্রকাশ্য CA সার্টিফিকেটটি res/raw/my_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>

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

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

আপনি হয়তো আপনার অ্যাপকে এমন অতিরিক্ত CA-কে বিশ্বাস করাতে চাইতে পারেন যা সিস্টেম দ্বারা বিশ্বস্ত নয়, যেমন যদি সিস্টেমে এখনও সেই CA অন্তর্ভুক্ত না থাকে অথবা CA-টি অ্যান্ড্রয়েড সিস্টেমে অন্তর্ভুক্ত হওয়ার জন্য প্রয়োজনীয় শর্ত পূরণ না করে। আপনি 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 থাকে। সাধারণত, IDE এবং বিল্ড টুলগুলো নন-রিলিজ বিল্ডের জন্য এই ফ্ল্যাগটি স্বয়ংক্রিয়ভাবে সেট করে দেয়।

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

নিচের উদ্ধৃতাংশে দেখানো হয়েছে কিভাবে 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>

সার্টিফিকেটের স্বচ্ছতা

দ্রষ্টব্য: সার্টিফিকেট স্বচ্ছতা সমর্থন শুধুমাত্র অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) থেকে উপলব্ধ।

সার্টিফিকেট ট্রান্সপারেন্সি (CT, RFC 6962 ) হলো ডিজিটাল সার্টিফিকেটের নিরাপত্তা বৃদ্ধির জন্য ডিজাইন করা একটি ইন্টারনেট স্ট্যান্ডার্ড। এটি CA-দেরকে তাদের ইস্যু করা সমস্ত সার্টিফিকেট একটি পাবলিক লগে জমা দিতে বাধ্য করে, যা সার্টিফিকেট ইস্যু করার প্রক্রিয়ায় স্বচ্ছতা ও জবাবদিহিতা বৃদ্ধি করে।

সমস্ত সার্টিফিকেটের একটি যাচাইযোগ্য রেকর্ড বজায় রাখার মাধ্যমে, CT ক্ষতিকারক ব্যক্তিদের জন্য সার্টিফিকেট জাল করা বা CA-দের ভুলবশত সার্টিফিকেট ইস্যু করাকে উল্লেখযোগ্যভাবে কঠিন করে তোলে। এটি ব্যবহারকারীদের ম্যান-ইন-দ্য-মিডল অ্যাটাক এবং অন্যান্য নিরাপত্তা ঝুঁকি থেকে রক্ষা করতে সাহায্য করে। আরও তথ্যের জন্য, transparency.dev- এর ব্যাখ্যাটি দেখুন। অ্যান্ড্রয়েডে CT কমপ্লায়েন্স সম্পর্কে আরও তথ্যের জন্য, অ্যান্ড্রয়েডের CT পলিসি দেখুন।

সার্টিফিকেট স্বচ্ছতার ডিফল্ট আচরণ এপিআই লেভেলের উপর নির্ভর করে:

• অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) থেকে সার্টিফিকেট ট্রান্সপারেন্সি ডিফল্টরূপে সক্রিয় করা হয়েছে। অ্যাপগুলো বিশ্বব্যাপী অথবা ডোমেইন-ভিত্তিক এই ফিচারটি নিষ্ক্রিয় করতে পারে।
• অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এ সার্টিফিকেট স্বচ্ছতা ডিফল্টরূপে নিষ্ক্রিয় থাকে। অ্যাপগুলো চাইলে এই ফিচারটি বিশ্বব্যাপী অথবা ডোমেইন-ভিত্তিক ভাবে চালু করতে পারে।
• অ্যান্ড্রয়েড ১৫ (এপিআই লেভেল ৩৫) এবং এর নিচের সংস্করণগুলোতে সার্টিফিকেট স্বচ্ছতা উপলব্ধ নয়।

সার্টিফিকেটের স্বচ্ছতা থেকে বেরিয়ে আসার বিকল্প বেছে নিন

দ্রষ্টব্য: অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এর জন্য, <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>

এনক্রিপ্টেড ক্লায়েন্ট হ্যালো

দ্রষ্টব্য: এনক্রিপ্টেড ক্লায়েন্ট হ্যালো সাপোর্ট শুধুমাত্র অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) থেকে পাওয়া যায় এবং এর জন্য অ্যাপের নেটওয়ার্কিং লাইব্রেরিতে ECH সাপোর্ট থাকা আবশ্যক। এখানে উল্লেখিত কনফিগারেশনটি কেবল তখনই কার্যকর হবে, যদি নেটওয়ার্কিং লাইব্রেরিটি ECH গ্রহণ করে থাকে।

এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH, RFC 9849 ) হলো TLS প্রোটোকলের একটি এক্সটেনশন, যা সুরক্ষিত সংযোগের গোপনীয়তা বাড়ানোর জন্য ডিজাইন করা হয়েছে। এটি প্রাথমিক TLS হ্যান্ডশেকের সংবেদনশীল অংশগুলিকে, বিশেষ করে সার্ভার নেম ইন্ডিকেশন (SNI) ফিল্ডকে এনক্রিপ্ট করার মাধ্যমে কাজ করে।

SNI এনক্রিপ্ট করার মাধ্যমে, ECH নেটওয়ার্ক মধ্যস্থতাকারীদের ক্লায়েন্ট যে নির্দিষ্ট ডোমেইন নামে সংযোগ করার চেষ্টা করছে তা পর্যবেক্ষণ করা থেকে বিরত রাখে। এটি ব্যবহারকারীদের ভিজিট করা ডোমেইনের ভিত্তিতে ফিঙ্গারপ্রিন্টিং বা নজরদারি থেকে রক্ষা করতে সাহায্য করে, যা স্ট্যান্ডার্ড TLS হ্যান্ডশেকে বিদ্যমান একটি গুরুতর গোপনীয়তা লঙ্ঘনের ঝুঁকি হ্রাস করে।

এনক্রিপ্টেড ক্লায়েন্ট হ্যালো-এর ডিফল্ট আচরণ এপিআই লেভেলের উপর নির্ভর করে:

• অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) থেকে, ইসিএইচ ডিফল্টরূপে 'অপরচুনিস্টিক' মোডে ব্যবহৃত হয়। অ্যাপগুলো এই ফিচারটি বন্ধ করতে পারে অথবা বিশ্বব্যাপী বা ডোমেইন-ভিত্তিক এর আচরণ পরিবর্তন করতে পারে।
• অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) এবং এর নিচের সংস্করণগুলোতে ECH উপলব্ধ নয়।

এনক্রিপ্টেড ক্লায়েন্ট হ্যালো থেকে অপ্ট আউট করুন

আপনি এই ফিচারটি নিষ্ক্রিয় করে এর ব্যবহার বন্ধ করতে পারেন। উদাহরণস্বরূপ, যদি আপনি শুধুমাত্র 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>

স্পষ্ট পাঠ্য ট্র্যাফিক

ডেভেলপাররা তাদের অ্যাপ্লিকেশনের জন্য ক্লিয়ারটেক্সট ট্র্যাফিক (HTTPS-এর পরিবর্তে এনক্রিপ্টবিহীন HTTP প্রোটোকল ব্যবহার করা) চালু বা বন্ধ করতে পারেন। আরও বিস্তারিত জানতে NetworkSecurityPolicy.isCleartextTrafficPermitted() দেখুন।

ক্লিয়ারটেক্সট ট্র্যাফিকের ডিফল্ট আচরণ এপিআই লেভেলের উপর নির্ভর করে:

• অ্যান্ড্রয়েড ৮.১ (এপিআই লেভেল ২৭) পর্যন্ত, ক্লিয়ারটেক্সট সাপোর্ট ডিফল্টরূপে সক্রিয় থাকে। অতিরিক্ত নিরাপত্তার জন্য অ্যাপ্লিকেশনগুলো ক্লিয়ারটেক্সট ট্র্যাফিক থেকে অপ্ট-আউট করতে পারে।
• অ্যান্ড্রয়েড ৯ (এপিআই লেভেল ২৮) থেকে ক্লিয়ারটেক্সট সাপোর্ট ডিফল্টরূপে নিষ্ক্রিয় থাকে। যেসব অ্যাপ্লিকেশনের ক্লিয়ারটেক্সট ট্র্যাফিকের প্রয়োজন, তারা এটি চালু করতে পারে।

স্পষ্ট টেক্সট ট্র্যাফিক থেকে অপ্ট আউট করুন

দ্রষ্টব্য: এই বিভাগের নির্দেশনা শুধুমাত্র অ্যান্ড্রয়েড ৮.১ (এপিআই লেভেল ২৭) বা তার নিম্নতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলোর ক্ষেত্রে প্রযোজ্য।

আপনার অ্যাপ যদি শুধুমাত্র সুরক্ষিত সংযোগ ব্যবহার করে কোনো গন্তব্যের সাথে যুক্ত হতে চায়, তাহলে আপনি সেই গন্তব্যগুলিতে ক্লিয়ারটেক্সট ট্র্যাফিক সমর্থন করা থেকে বিরত থাকতে পারেন। এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উৎস থেকে প্রাপ্ত URL-এর পরিবর্তনের কারণে অ্যাপে ঘটা আকস্মিক ত্রুটি প্রতিরোধ করতে সাহায্য করে।

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

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

স্পষ্ট টেক্সট ট্র্যাফিকের জন্য অপ্ট ইন করুন

দ্রষ্টব্য: এই বিভাগের নির্দেশনা শুধুমাত্র অ্যান্ড্রয়েড ৯ (এপিআই লেভেল ২৮) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলোর ক্ষেত্রে প্রযোজ্য।

আপনার অ্যাপকে যদি ক্লিয়ারটেক্সট ট্র্যাফিক (HTTP) ব্যবহার করে এমন কোনো গন্তব্যের সাথে সংযোগ স্থাপন করতে হয়, তাহলে আপনি সেই গন্তব্যগুলিতে ক্লিয়ারটেক্সট সমর্থন করার বিকল্পটি বেছে নিতে পারেন।

উদাহরণস্বরূপ, আপনি আপনার অ্যাপকে 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>

আপনার অ্যাপকে যদি কোনো ডোমেইনে ক্লিয়ারটেক্সট ট্র্যাফিকের জন্য অপ্ট-ইন করতে হয়, তাহলে base-config এ cleartextTrafficPermitted="true" সেট করুন। মনে রাখবেন, এই অনিরাপদ কনফিগারেশনটি যথাসম্ভব এড়িয়ে চলা উচিত।

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
    </base-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>

লোকালহোস্ট কনফিগারেশন

লোকালহোস্ট সংযোগের জন্য নেটওয়ার্ক নিরাপত্তা বৈশিষ্ট্য প্রয়োগ করা সাধারণত অপ্রয়োজনীয়। উদাহরণস্বরূপ, লোকালহোস্ট সংযোগের জন্য সার্টিফিকেট স্বচ্ছতার খুব কমই প্রয়োজন হয়।

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) এবং এর পরবর্তী সংস্করণগুলোতে, লোকালহোস্টের জন্য কোনো কনফিগারেশন সংজ্ঞায়িত করা না থাকলে, একটি অন্তর্নিহিত কনফিগারেশন অন্তর্ভুক্ত থাকে। ডিফল্টরূপে, এই কনফিগারেশনটি নিম্নলিখিত কাজগুলো করে থাকে:

• স্পষ্ট টেক্সট ট্র্যাফিকের অনুমতি দেয়।
• সার্টিফিকেটের স্বচ্ছতা (CT) বলবৎ করে না।
• সার্টিফিকেট পিনিং বাধ্যতামূলক করে না।
• ট্রাস্ট অ্যাঙ্করগুলির জন্য <base-config> কে দায়িত্ব অর্পণ করে।

একটি কনফিগারেশনকে লোকালহোস্টকে লক্ষ্য করে তৈরি বলে মনে করা হয়, যদি ডোমেইনটি হয়:

• localhost
• ip6-localhost অথবা
• একটি সংখ্যাসূচক আইপি ঠিকানা এবং InetAddress.isLoopback() true (উদাহরণস্বরূপ, 127.0.0.1 বা [::1] )

কনফিগারেশন ফাইল ফরম্যাট

নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ফিচারটি একটি 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>

নিম্নলিখিত বিভাগগুলিতে ফাইল ফরম্যাটের সিনট্যাক্স এবং অন্যান্য বিবরণ বর্ণনা করা হয়েছে।

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

এতে থাকতে পারে:

<base-config> এর ০ অথবা ১
যেকোনো সংখ্যক <domain-config>
<debug-overrides> এর ০ বা ১

<বেস-কনফিগারেশন>

সিনট্যাক্স:

<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>

এতে থাকতে পারে:

<trust-anchors> <certificateTransparency> <domainEncryption>

বর্ণনা:

যেসব সংযোগের গন্তব্য কোনো domain-config আওতাভুক্ত নয়, সেগুলোর জন্য ব্যবহৃত ডিফল্ট কনফিগারেশন।

যেসব মান সেট করা হয়নি, সেগুলো প্ল্যাটফর্মের ডিফল্ট মান ব্যবহার করবে।

অ্যান্ড্রয়েড ৯ (এপিআই লেভেল ২৮) এবং এর পরবর্তী সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলির ডিফল্ট কনফিগারেশন নিম্নরূপ:

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

অ্যান্ড্রয়েড ৭.০ (এপিআই লেভেল ২৪) থেকে অ্যান্ড্রয়েড ৮.১ (এপিআই লেভেল ২৭) পর্যন্ত টার্গেট করা অ্যাপগুলোর জন্য ডিফল্ট কনফিগারেশনটি নিম্নরূপ:

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

অ্যান্ড্রয়েড ৬.০ (এপিআই লেভেল ২৩) এবং এর নিচের সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলোর জন্য ডিফল্ট কনফিগারেশনটি নিম্নরূপ:

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

<ডোমেইন-কনফিগারেশন>

সিনট্যাক্স:

<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>

এতে থাকতে পারে:

১ বা তার বেশি <domain>
০ অথবা ১ <certificateTransparency>
০ অথবা ১ <trust-anchors> >
০ অথবা ১ <pin-set>
০ অথবা ১ <domainEncryption> >
যেকোনো সংখ্যক নেস্টেড <domain-config>

বর্ণনা:

domain উপাদান দ্বারা সংজ্ঞায়িত নির্দিষ্ট গন্তব্যস্থলে সংযোগের জন্য ব্যবহৃত কনফিগারেশন।

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

<ডোমেইন>

সিনট্যাক্স:

<domain includeSubdomains=["true" | "false"]>example.com</domain>

বৈশিষ্ট্য:

includeSubdomains

যদি "true" , তাহলে এই ডোমেইন নিয়মটি ডোমেইন এবং এর সমস্ত সাবডোমেইনের সাথে, এমনকি সাবডোমেইনের সাবডোমেইনের সাথেও মিলে যায়। অন্যথায়, নিয়মটি শুধুমাত্র হুবহু মিলের ক্ষেত্রে প্রযোজ্য হয়।

<সনদ স্বচ্ছতা>

সিনট্যাক্স:

<certificateTransparency enabled=["true" | "false"]/>

বর্ণনা:

যদি true , তাহলে অ্যাপটি সার্টিফিকেট যাচাই করার জন্য সার্টিফিকেট ট্রান্সপারেন্সি লগ ব্যবহার করবে। যখন কোনো অ্যাপ তার নিজস্ব সার্টিফিকেট (বা ইউজার স্টোর) ব্যবহার করে, তখন সম্ভবত সার্টিফিকেটটি পাবলিক নয় এবং তাই সার্টিফিকেট ট্রান্সপারেন্সি ব্যবহার করে যাচাইযোগ্য নয়। ডিফল্টরূপে, এই ক্ষেত্রগুলির জন্য যাচাইকরণ নিষ্ক্রিয় থাকে। ডোমেইন কনফিগারেশনে <certificateTransparency enabled="true"/> ব্যবহার করে যাচাইকরণটি জোর করে চালু করা এখনও সম্ভব। প্রতিটি <domain-config> এর জন্য, মূল্যায়নটি এই ক্রম অনুসরণ করে:

1. যদি certificateTransparency সক্রিয় করা থাকে, তাহলে যাচাইকরণ সক্রিয় করুন।
2. যদি কোনো <trust-anchors> "user" বা ইনলাইন (যেমন, "@raw/cert.pem" ) হয়, তাহলে যাচাইকরণ নিষ্ক্রিয় করুন।
3. অন্যথায়, উত্তরাধিকারসূত্রে প্রাপ্ত কনফিগারেশনের উপর নির্ভর করুন।

<ডোমেইন এনক্রিপশন>

সিনট্যাক্স:

<domainEncryption mode=["enabled" | "opportunistic" | "disabled"]/>

বর্ণনা:

নির্দিষ্ট ডোমেইনগুলিতে সংযোগের জন্য এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH) আচরণ নিয়ন্ত্রণ করে।

দ্রষ্টব্য: ` domainEncryption এলিমেন্টটি অ্যাপের নেটওয়ার্কিং লাইব্রেরির ECH সমর্থনের উপর নির্ভরশীল। নির্দিষ্ট আচরণটি কেবল তখনই কার্যকর হয়, যদি নেটওয়ার্কিং লাইব্রেরিটি ECH গ্রহণ করে থাকে। অ্যাপগুলোর নিজেদের ECH কনফিগারেশন পরিচালনা করার কথা নয় এবং TLS হ্যান্ডশেক স্থাপনের সময় এর জন্য তাদের নেটওয়ার্কিং লাইব্রেরির উপর নির্ভর করা উচিত।

mode অ্যাট্রিবিউটটি নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:

• enabled : TLS হ্যান্ডশেক স্থাপনের সময় ECH কনফিগারেশন প্রদান করা হলে সংযোগটিতে ECH বাধ্যতামূলক করুন, এবং অন্যথায় ECH GREASE সক্রিয় করুন।
• opportunistic : TLS হ্যান্ডশেক স্থাপনের সময় ECH কনফিগারেশন প্রদান করা হলে সংযোগে ECH ব্যবহার করুন। যদি সংযোগ ব্যর্থ হয় বা কনফিগারেশন প্রদান করা না হয়, তবে একটি সাধারণ নন-এনক্রিপ্টেড TLS ClientHello-তে ফিরে যান। এই মোডটি ECH GREASE সক্রিয় করে না।
• disabled : কোনো সংযোগেই ECH বা ECH GREASE ব্যবহার করার চেষ্টা করবেন না।

নির্দিষ্ট করে না দেওয়া হলে, ডিফল্ট mode হলো "opportunistic" ।

<ডিবাগ-ওভাররাইড>

সিনট্যাক্স:

<debug-overrides>
    ...
</debug-overrides>

এতে থাকতে পারে:

০ অথবা ১ <trust-anchors> >

বর্ণনা:

যখন android:debuggable-এর মান "true" হয়, তখন এই ওভাররাইডগুলো প্রয়োগ করা হবে; সাধারণত IDE এবং বিল্ড টুল দ্বারা তৈরি নন-রিলিজ বিল্ডগুলোর ক্ষেত্রে এমনটাই হয়ে থাকে। 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 ডিবাগ করার জন্য অথবা আপনার অ্যাপের সুরক্ষিত ট্র্যাফিকের উপর ম্যান-ইন-দ্য-মিডল আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।

ডিফল্ট মান "false" যদি না এটি কোনো debug-overrides এলিমেন্টে নির্দিষ্ট করা থাকে, সেক্ষেত্রে ডিফল্ট মান "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" সমর্থিত।