নেটওয়ার্ক প্রোটোকলের মাধ্যমে সুরক্ষা

আপনার অ্যাপের ডেটা সুরক্ষিত রাখতে ক্লায়েন্ট-সার্ভার এনক্রিপ্ট করা ইন্টার‍্যাকশন ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) ব্যবহার করে।

এই নিবন্ধে সুরক্ষিত নেটওয়ার্ক প্রোটোকল সংক্রান্ত পেশাদার পদ্ধতি এবং পাবলিক-কী ইনফ্রাস্ট্রাকচার (PKI) সম্পর্কিত পেশাদার পদ্ধতি নিয়ে আলোচনা করা হয়েছে। আরও জানতে Android নিরাপত্তা ওভারভিউ এবং অনুমতি ওভারভিউ পড়ুন।

ধারণা

TLS সার্টিফিকেট সহ সার্ভারে একটি সর্বজনীন কী এবং একটি ম্যাচিং ব্যক্তিগত কী থাকে। TLS হ্যান্ডশেক চলাকালীন সার্ভার তার সার্টিফিকেটে স্বাক্ষর করার জন্য পাবলিক-কী ক্রিপ্টোগ্রাফি ব্যবহার করে।

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

তবে, সার্ভার 'কী' রোটেশন ব্যবহার করে সার্টিফিকেটের পাবলিক 'কী' পরিবর্তন করে নতুন 'কী' ব্যবহার করতে পারে। সার্ভার কনফিগারেশন পরিবর্তন করার জন্য ক্লায়েন্ট অ্যাপ আপডেট করা প্রয়োজন। সার্ভারটি যদি কোনও থার্ড-পার্টি ওয়েব পরিষেবা হয়, যেমন কোনও ওয়েব ব্রাউজার বা ইমেল অ্যাপ, তাহলে ক্লায়েন্ট অ্যাপ কখন আপডেট করতে হবে তা জানা আরও কঠিন।

সার্ভার সাধারণত সার্টিফিকেট ইস্যু করার জন্য সার্টিফিকেট অথরিটি (CA) সার্টিফিকেটের উপর নির্ভর করে, যা সময়ের সাথে সাথে ক্লায়েন্ট-সাইড কনফিগারেশনকে আরও স্থির রাখে। CA তার ব্যক্তিগত কী ব্যবহার করে সার্ভার সার্টিফিকেট স্বাক্ষর করে। ক্লায়েন্ট তখন চেক করে দেখতে পারে যে সার্ভারের কাছে প্ল্যাটফর্ম-পরিচিত CA সার্টিফিকেট আছে কিনা।

হোস্ট প্ল্যাটফর্মে সাধারণত বিশ্বস্ত CA-এর তালিকা থাকে। Android 8.0 (API লেভেল ২৬)-এ ১০০টির বেশি CA অন্তর্ভুক্ত আছে যা প্রতিটি ভার্সনে আপডেট করা হয় এবং ডিভাইস অনুযায়ী পরিবর্তন হয় না।

ক্লায়েন্ট অ্যাপের সার্ভার যাচাই করার জন্য একটি মেকানিজম প্রয়োজন কারণ CA অসংখ্য সার্ভারের জন্য সার্টিফিকেট অফার করে। CA-এর সার্টিফিকেট, নির্দিষ্ট নাম, যেমন gmail.com বা ওয়াইল্ডকার্ড, যেমন *.google.com ব্যবহার করে সার্ভার শনাক্ত করে।

কোনও ওয়েবসাইটের সার্ভার সার্টিফিকেট সংক্রান্ত তথ্য দেখতে, পোর্ট নম্বর পাস করে openssl টুলের s_client কমান্ড ব্যবহার করুন। ডিফল্ট হিসেবে, HTTPS পোর্ট 443 ব্যবহার করে।

কমান্ডটি openssl s_client আউটপুটকে openssl x509-এ ট্রান্সমিট করে, যা সার্টিফিকেট সংক্রান্ত তথ্যকে X.509 স্ট্যান্ডার্ড-এ ফর্ম্যাট করে। কমান্ডটি বিষয় (সার্ভারের নাম) এবং ইস্যুকারী (CA) সম্পর্কে অনুরোধ করে।

openssl s_client -connect WEBSITE-URL:443 | \
  openssl x509 -noout -subject -issuer

HTTPS-এর একটি উদাহরণ

ধরে নেওয়া যাক, আপনার কাছে একটি ওয়েব সার্ভার আছে এবং সেটি একটি সুপরিচিত CA-এর ইস্যু করা সার্টিফিকেট ব্যবহার করে। সেক্ষেত্রে, নিম্নলিখিত কোডে যেভাবে দেখানো হয়েছে, সেইভাবে আপনি একটি সুরক্ষিত অনুরোধ করতে পারেন:

Kotlin

val url = URL("https://wikipedia.org")
val urlConnection: URLConnection = url.openConnection()
val inputStream: InputStream = urlConnection.getInputStream()
copyInputStreamToOutputStream(inputStream, System.out)

জাভা

URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

HTTP অনুরোধ কাস্টমাইজ করতে, HttpURLConnection-এ কাস্ট করুন। Android HttpURLConnection ডকুমেন্টেশনে অনুরোধ ও রেসপন্স হেডার ম্যানেজ করা, কন্টেন্ট প্রকাশ করা, কুকি ম্যানেজ করা, প্রক্সি ব্যবহার করা, রেসপন্স ক্যাশে করা এবং আরও অনেক কিছুর উদাহরণ অন্তর্ভুক্ত রয়েছে। Android ফ্রেমওয়ার্ক এই API ব্যবহার করে সার্টিফিকেট ও হোস্টনেম যাচাই করে।

সম্ভব হলে এইসব API ব্যবহার করুন। নিম্নলিখিত বিভাগে সাধারণ সমস্যাগুলি কভার করা হয়েছে যেগুলির জন্য বিভিন্ন সমাধান প্রয়োজন।

সার্ভার সার্টিফিকেট যাচাই করার সময় হওয়া সাধারণ সমস্যা

ধরুন, কন্টেন্ট রিটার্ন করার পরিবর্তে, getInputStream(), একটি ব্যতিক্রম থ্রো করে:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
        at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
        at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

একাধিক কারণে এমনটি হতে পারে, যার মধ্যে রয়েছে:

  1. সার্ভার সার্টিফিকেট ইস্যু করা CA অজানা ছিল।
  2. সার্ভার সার্টিফিকেটটি CA দ্বারা স্বাক্ষরিত হয়নি, তবে এটি স্ব-স্বাক্ষরিত ছিল।
  3. সার্ভার কনফিগারেশনে ইন্টারমিডিয়েট CA নেই।

সার্ভারের সাথে আপনার কানেকশন সুরক্ষিত রেখে কীভাবে এইসব সমস্যার সমাধান করবেন তা নিম্নলিখিত বিভাগে আলোচনা করা হয়েছে।

অজানা সার্টিফিকেট অথরিটি

SSLHandshakeException হওয়ার কারণ হল সিস্টেম CA-কে বিশ্বাস করে না। এটি হতে পারে কারণ আপনার কাছে এমন একটি নতুন CA থেকে সার্টিফিকেট আছে যা Android বিশ্বাস করে না বা আপনার অ্যাপটি CA ছাড়াই আগের ভার্সনে কাজ করছে। এটি ব্যক্তিগত হওয়ার কারণে, CA খুব কমই জানা যায়। বেশিরভাগ ক্ষেত্রে, CA অজানা থাকে কারণ এটি কোনও পাবলিক CA নয়, বরং কোনও সংস্থা যেমন সরকার, কর্পোরেশন বা শিক্ষা প্রতিষ্ঠান নিজস্ব ব্যবহারের জন্য এটি ইস্যু করে।

আপনার অ্যাপের কোড পরিবর্তন না করেই কাস্টম CA-কে বিশ্বাস করতে, আপনার নেটওয়ার্ক নিরাপত্তা কনফিগারেশন পরিবর্তন করুন।

সতর্কতা: অনেক ওয়েবসাইট একটি খারাপ বিকল্প সমাধান বর্ণনা করে, যা হল এমন একটি TrustManager ইনস্টল করা যা কিছুই করে না। এটি করলে, পাবলিক ওয়াই-ফাই হটস্পট ব্যবহার করার সময় আপনার ব্যবহারকারীরা আক্রমণের শিকার হতে পারেন, কারণ আক্রমণকারী ডিএনএস ট্রিক ব্যবহার করে আপনার ব্যবহারকারীর ট্রাফিক এমন একটি প্রক্সির মাধ্যমে পাঠাতে পারে যা আপনার সার্ভার হিসেবে নিজেকে দেখায়। আক্রমণকারী তখন পাসওয়ার্ড ও অন্যান্য ব্যক্তিগত ডেটা রেকর্ড করতে পারে। এটি কাজ করে কারণ আক্রমণকারী একটি সার্টিফিকেট তৈরি করতে পারে এবং কোনও TrustManager ছাড়া, সার্টিফিকেটটি কোনও বিশ্বস্ত উৎস থেকে এসেছে কিনা তা যাচাই করা যায় না। আপনি এই ধরনের আক্রমণ ব্লক করতে পারবেন না। তাই সাময়িকভাবেও এটি করবেন না। পরিবর্তে, আপনার অ্যাপকে সার্ভারের সার্টিফিকেট ইস্যুকারীকে বিশ্বাস করতে দিন।

নিজে সাইন-ইন করা সার্ভার সার্টিফিকেট

দ্বিতীয়ত, SSLHandshakeException সেল্ফ-সাইনড সার্টিফিকেটের কারণে হতে পারে, যা সার্ভারকে নিজস্ব CA করে তোলে। এটি একটি অজানা সার্টিফিকেট অথরিটির মতো, তাই আপনার সেল্ফ-সাইনড সার্টিফিকেটকে বিশ্বাস করতে আপনার অ্যাপ্লিকেশনের নেটওয়ার্ক নিরাপত্তা কনফিগারেশন পরিবর্তন করুন।

অন্তর্বর্তী সার্টিফিকেট অথরিটি নেই

তৃতীয়ত, SSLHandshakeException ইন্টারমিডিয়েট CA না থাকার কারণে হয়। সর্বজনীন CA খুব কমই সার্ভার সার্টিফিকেটে স্বাক্ষর করে। পরিবর্তে, রুট CA ইন্টারমিডিয়েট CA-তে স্বাক্ষর করে।

ঝুঁকি কমাতে, CA-গুলি রুট CA অফলাইনে রাখে। তবে, Android-এর মতো অপারেটিং সিস্টেম সাধারণত সরাসরি শুধুমাত্র রুট CA-কে বিশ্বাস করে, যার ফলে সার্ভার সার্টিফিকেট—যা অন্তর্বর্তী CA দ্বারা স্বাক্ষরিত—এবং সার্টিফিকেট যাচাইকারীর মধ্যে একটি ছোট বিশ্বাসের ব্যবধান থেকে যায়, যা রুট CA-কে শনাক্ত করে।

এই বিশ্বাসের ব্যবধান দূর করতে, সার্ভার TLS হ্যান্ডশেকের সময় সার্ভার CA থেকে যেকোনও ইন্টারমিডিয়েটের মাধ্যমে একটি বিশ্বস্ত রুট CA-তে সার্টিফিকেটের একটি চেইন পাঠায়।

যেমন, openssl s_client কমান্ডের মাধ্যমে দেখা mail.google.com সার্টিফিকেট চেন এখানে দেওয়া হল:

$ openssl s_client -connect mail.google.com:443
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---

এটি দেখায় যে সার্ভার mail.google.com-এর জন্য একটি সার্টিফিকেট পাঠায় যা Thawte SGC CA দ্বারা ইস্যু করা হয়েছে, এটি একটি অন্তর্বর্তী CA এবং দ্বিতীয় সার্টিফিকেট Thawte SGC CA-এর জন্য Verisign CA দ্বারা ইস্যু করা হয়েছে, এটি প্রাথমিক CA যা Android-এর দ্বারা বিশ্বস্ত।

তবে, কোনও সার্ভার প্রয়োজনীয় ইন্টারমিডিয়েট CA অন্তর্ভুক্ত করার জন্য কনফিগার করা নাও থাকতে পারে। যেমন, এখানে এমন একটি সার্ভার দেখানো হয়েছে যা Android ব্রাউজারে সমস্যা এবং Android অ্যাপে ব্যতিক্রমের কারণ হতে পারে:

$ openssl s_client -connect egov.uscis.gov:443
---
Certificate chain
 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---

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

কিছু সাইট ইচ্ছাকৃতভাবে রিসোর্স-সার্ভিং সেকেন্ডারি ওয়েব সার্ভারের জন্য এটি করে। ব্যান্ডউইথ বাঁচাতে, তারা সম্পূর্ণ সার্টিফিকেট চেইন সহ সার্ভার থেকে তাদের প্রধান HTML পৃষ্ঠা পরিবেশন করতে পারে, কিন্তু তাদের ছবি, CSS এবং JavaScript CA ছাড়াই। তবে, মাঝে মাঝে এইসব সার্ভার এমন কোনও ওয়েব পরিষেবা প্রদান করতে পারে যা আপনি Android অ্যাপ থেকে অ্যাক্সেস করার চেষ্টা করছেন, যা ততটা সহনশীল নয়।

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

SSLSocket সরাসরি ব্যবহার করা সম্পর্কে সতর্কতা

এখনও পর্যন্ত, উদাহরণগুলি HttpsURLConnection ব্যবহার করে HTTPS-এর উপর ফোকাস করেছে। কখনও কখনও অ্যাপকে HTTPS থেকে আলাদা TLS ব্যবহার করতে হয়। যেমন, কোনও ইমেল অ্যাপ SMTP, POP3 বা IMAP-এর TLS ভ্যারিয়েন্ট ব্যবহার করতে পারে। এইসব ক্ষেত্রে, অ্যাপ সরাসরি SSLSocket ব্যবহার করতে পারে, ঠিক যেভাবে HttpsURLConnection ইন্টার্নালি করে।

সার্টিফিকেট যাচাইকরণ সংক্রান্ত সমস্যার সমাধান করার জন্য এখনও পর্যন্ত যেসব কৌশল বর্ণনা করা হয়েছে, সেগুলি SSLSocket-এর ক্ষেত্রেও প্রযোজ্য। আসলে, কাস্টম TrustManager ব্যবহার করার সময়, HttpsURLConnection-এ যা পাস করা হয় তা হল SSLSocketFactory। তাই, আপনাকে SSLSocket-এর সাথে কাস্টম TrustManager ব্যবহার করতে হলে, একই ধাপ অনুসরণ করুন এবং SSLSocket তৈরি করতে সেই SSLSocketFactory ব্যবহার করুন।

সতর্কতা: SSLSocket হোস্টনেম যাচাইকরণ করে না। আপনার অ্যাপের নিজস্ব হোস্টনেম যাচাইকরণ করার দায়িত্ব আপনার, বিশেষত প্রত্যাশিত হোস্টনেমের সাথে getDefaultHostnameVerifier() কল করার মাধ্যমে। এছাড়াও, মনে রাখবেন যে HostnameVerifier.verify() কোনও সমস্যার ক্ষেত্রে ব্যতিক্রম দেখায় না। পরিবর্তে, এটি একটি বুলিয়ান ফলাফল প্রদান করে যা আপনাকে অবশ্যই স্পষ্টভাবে চেক করতে হবে।

সার্টিফিকেট যাচাইকরণ

TLS, CA-এর উপর নির্ভর করে যাতে শুধুমাত্র সার্ভার ও ডোমেনের যাচাই করা মালিকদের সার্টিফিকেট ইস্যু করা যায়। বিরল ক্ষেত্রে, CA-কে প্রতারিত করা হয় অথবা Comodo বা DigiNotar-এর ক্ষেত্রে, লঙ্ঘন করা হয়, যার ফলে সার্ভার বা ডোমেনের মালিক ছাড়া অন্য কাউকে হোস্টনেমের জন্য সার্টিফিকেট ইস্যু করা হয়।

এই ঝুঁকি কমাতে, Android সিস্টেম-ব্যাপী সার্টিফিকেট প্রত্যাহার করার বিষয়টি ম্যানেজ করে। এটি ব্লকলিস্ট এবং সার্টিফিকেট ট্রান্সপারেন্সির সমন্বয়ে করা হয়, অনলাইন সার্টিফিকেট যাচাইকরণের উপর নির্ভর না করেই। এছাড়াও, Android, TLS হ্যান্ডশেকের সাথে স্ট্যাপল করা OCSP উত্তর যাচাই করবে।

আপনার অ্যাপে সার্টিফিকেট ট্রান্সপারেন্সি চালু করতে, আমাদের নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ডকুমেন্টেশনের সার্টিফিকেট ট্রান্সপারেন্সি চালু করুন বিভাগটি দেখুন।

নির্দিষ্ট সার্টিফিকেটে আপনার অ্যাপ সীমাবদ্ধ করা

সতর্কতা: সার্টিফিকেট পিন করা, অর্থাৎ আপনার অ্যাপের জন্য বৈধ বলে বিবেচিত সার্টিফিকেটগুলিকে আপনার আগে অনুমোদিত সার্টিফিকেটগুলিতে সীমাবদ্ধ করার অভ্যাস, Android অ্যাপের জন্য সাজেস্ট করা হয় না। ভবিষ্যতে সার্ভার কনফিগারেশনে পরিবর্তন, যেমন অন্য CA-তে পরিবর্তন করা, পিন করা সার্টিফিকেট সহ অ্যাপ রেন্ডার করা, ক্লায়েন্ট সফ্টওয়্যার আপডেট না পেলে সার্ভারে কানেক্ট করতে পারবে না।

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

ক্লায়েন্ট সার্টিফিকেট

এই নিবন্ধে সার্ভারের সাথে যোগাযোগ সুরক্ষিত করতে TLS-এর ব্যবহারের উপর ফোকাস করা হয়েছে। এছাড়াও, TLS ক্লায়েন্ট সার্টিফিকেটের ধারণাকে সমর্থন করে যা সার্ভারকে ক্লায়েন্টের পরিচয় যাচাই করতে দেয়। এই নিবন্ধের পরিধির বাইরে হলেও, এর সাথে যুক্ত টেকনিকগুলি কাস্টম TrustManager নির্দিষ্ট করার মতোই।

Nogotofail: নেটওয়ার্ক ট্রাফিক নিরাপত্তা টেস্টিং টুল

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

Nogotofail তিনটি প্রধান ব্যবহারের ক্ষেত্রে উপযোগী:

  • সমস্যা ও দুর্বলতা খুঁজে বের করা।
  • সমাধান যাচাই করা এবং রিগ্রেশন লক্ষ্য করা।
  • কোন অ্যাপ্লিকেশন ও ডিভাইস থেকে কী ধরনের ট্রাফিক জেনারেট হচ্ছে তা বোঝা।

Nogotofail, Android, iOS, Linux, Windows, ChromeOS, macOS এবং ইন্টারনেটের সাথে কানেক্ট করার জন্য আপনি ব্যবহার করেন এমন যেকোনও ডিভাইসে কাজ করে। Android ও Linux-এ সেটিংস কনফিগার করা ও বিজ্ঞপ্তি পাওয়ার জন্য ক্লায়েন্ট উপলভ্য এবং অ্যাটাক ইঞ্জিন নিজেই রাউটার, VPN সার্ভার বা প্রক্সি হিসেবে ডিপ্লয় করা যেতে পারে।

আপনি Nogotofail ওপেন সোর্স প্রোজেক্ট থেকে টুলটি অ্যাক্সেস করতে পারবেন।

SSL ও TLS-এ আপডেট

Android 10

Google Chrome-এর মতো কিছু ব্রাউজার ব্যবহারকারীদের একটি সার্টিফিকেট বেছে নেওয়ার অনুমতি দেয় যখন একটি TLS সার্ভার TLS হ্যান্ডশেকের অংশ হিসেবে একটি সার্টিফিকেট অনুরোধ মেসেজ পাঠায়। Android 10 থেকে, KeyChain অবজেক্টগুলি ব্যবহারকারীদের একটি সার্টিফিকেট নির্বাচনের প্রম্পট দেখানোর জন্য KeyChain.choosePrivateKeyAlias() কল করার সময় ইস্যুকারী এবং কী স্পেসিফিকেশন প্যারামিটারগুলিকে সম্মান করে। বিশেষ করে, এই প্রম্পটে এমন কোনও বিকল্প নেই যা সার্ভারের স্পেসিফিকেশন মেনে চলে না।

ব্যবহারকারী বেছে নিতে পারেন এমন কোনও সার্টিফিকেট উপলভ্য না থাকলে, যেমন সার্ভার স্পেসিফিকেশনের সাথে কোনও সার্টিফিকেট না মিললে অথবা ডিভাইসে কোনও সার্টিফিকেট ইনস্টল করা না থাকলে, সার্টিফিকেট বেছে নেওয়ার প্রম্পট একেবারেই দেখানো হয় না।

এছাড়াও, Android 10 বা তার পরবর্তী ভার্সনে, KeyChain অবজেক্টে কী বা CA সার্টিফিকেট ইমপোর্ট করার জন্য ডিভাইস স্ক্রিন লক থাকা আবশ্যক নয়।

TLS 1.3 ডিফল্ট হিসেবে চালু করা আছে

Android 10 ও তার পরবর্তী যেকোনও ভার্সনে, সব TLS কানেকশনের জন্য TLS 1.3 ডিফল্ট হিসেবে চালু করা থাকে। আমাদের TLS 1.3 প্রয়োগ করার ব্যাপারে কিছু গুরুত্বপূর্ণ তথ্য এখানে দেওয়া হল:

  • TLS 1.3 সাইফার স্যুট কাস্টমাইজ করা যাবে না। TLS 1.3 চালু থাকলে কাজ করে এমন TLS 1.3 সাইফার স্যুট সবসময় চালু থাকে। setEnabledCipherSuites() কল করে সেগুলি বন্ধ করার যেকোনও প্রচেষ্টা উপেক্ষা করা হয়।
  • TLS 1.3 নেগোশিয়েট করা হলে, সেশন ক্যাশে সেশন যোগ করার আগে HandshakeCompletedListener অবজেক্ট কল করা হয়। (TLS 1.2 এবং অন্যান্য পূর্ববর্তী ভার্সনে, সেশন ক্যাশে সেশন যোগ করার পরে এই অবজেক্টগুলিকে কল করা হয়।)
  • কিছু পরিস্থিতিতে যেখানে SSLEngine ইনস্ট্যান্স Android-এর আগের ভার্সনে SSLHandshakeException থ্রো করে, সেখানে এই ইনস্ট্যান্স Android 10 এবং তার পরবর্তী ভার্সনে SSLProtocolException থ্রো করে।
  • 0-RTT মোড কাজ করে না।

আপনি চাইলে, SSLContext.getInstance("TLSv1.2") কল করে TLS 1.3 বন্ধ করা আছে এমন SSLContext পেতে পারেন। এছাড়াও, আপনি উপযুক্ত অবজেক্টে setEnabledProtocols() কল করে কানেকশন প্রতি প্রোটোকল ভার্সন চালু বা বন্ধ করতে পারবেন।

SHA-1-এর মাধ্যমে সাইন করা সার্টিফিকেট TLS-এ বিশ্বস্ত নয়

Android 10-এ, SHA-1 হ্যাশ অ্যালগরিদম ব্যবহার করা সার্টিফিকেট TLS কানেকশনে বিশ্বস্ত নয়। ২০১৬ সাল থেকে রুট CA এই ধরনের সার্টিফিকেট ইস্যু করেনি এবং Chrome বা অন্যান্য প্রধান ব্রাউজারে এগুলি আর বিশ্বস্ত নয়।

SHA-1 ব্যবহার করে সার্টিফিকেট উপস্থাপন করে এমন সাইটের সাথে কানেক্ট করার যেকোনও প্রচেষ্টা ব্যর্থ হয়।

KeyChain-এর আচরণে পরিবর্তন ও উন্নতি

Google Chrome-এর মতো কিছু ব্রাউজার, TLS হ্যান্ডশেকের অংশ হিসেবে TLS সার্ভার সার্টিফিকেট অনুরোধ মেসেজ পাঠালে, ব্যবহারকারীদের সার্টিফিকেট বেছে নেওয়ার অনুমতি দেয়। Android 10 থেকে, KeyChain অবজেক্ট ইস্যুকারী ও কী স্পেসিফিকেশন প্যারামিটারকে সম্মান করে যখন KeyChain.choosePrivateKeyAlias()-কে কল করে ব্যবহারকারীকে সার্টিফিকেট বেছে নেওয়ার প্রম্পট দেখায়। বিশেষ করে, এই প্রম্পটে এমন কোনও বিকল্প নেই যা সার্ভারের স্পেসিফিকেশন মেনে চলে না।

ব্যবহারকারী বেছে নিতে পারবেন এমন কোনও সার্টিফিকেট উপলভ্য না থাকলে, যেমন কোনও সার্টিফিকেট সার্ভারের স্পেসিফিকেশনের সাথে না মিললে অথবা ডিভাইসে কোনও সার্টিফিকেট ইনস্টল করা না থাকলে, সার্টিফিকেট বেছে নেওয়ার প্রম্পট একেবারেই দেখানো হয় না।

এছাড়াও, Android 10 বা তার পরবর্তী ভার্সনে, KeyChain অবজেক্টে কী বা CA সার্টিফিকেট ইমপোর্ট করার জন্য ডিভাইস স্ক্রিন লক থাকা আবশ্যক নয়।

অন্যান্য TLS ও ক্রিপ্টোগ্রাফি সংক্রান্ত পরিবর্তন

TLS এবং ক্রিপ্টোগ্রাফি লাইব্রেরিতে বেশ কিছু ছোটখাটো পরিবর্তন করা হয়েছে যা Android 10-এ কার্যকর হয়:

  • AES/GCM/NoPadding এবং ChaCha20/Poly1305/NoPadding সাইফার getOutputSize() থেকে আরও সঠিক বাফার সাইজ রিটার্ন করে।
  • TLS_FALLBACK_SCSV সাইফার স্যুটটি TLS 1.2 বা তার বেশি সর্বাধিক প্রোটোকল সহ কানেকশনের চেষ্টা থেকে বাদ দেওয়া হয়েছে। TLS সার্ভার ইমপ্লিমেন্টেশনে উন্নতির কারণে, আমরা TLS-এক্সটার্নাল ফলব্যাক চেষ্টা করার সাজেশন দিই না। পরিবর্তে, আমরা TLS ভার্সন নেগোসিয়েশনের উপর নির্ভর করার সাজেশন দিই।
  • ChaCha20-Poly1305 হল ChaCha20/Poly1305/NoPadding-এর একটি উপনাম।
  • ট্রেলিং ডট সহ হোস্টনেমকে সঠিক SNI হোস্টনেম হিসেবে বিবেচনা করা হয় না।
  • সার্টিফিকেট উত্তরের জন্য সাইনিং কী বেছে নেওয়ার সময় CertificateRequest-এ supported_signature_algorithms এক্সটেনশন ব্যবহার করা হয়।
  • অস্বচ্ছ সাইনিং কী, যেমন Android Keystore থেকে পাওয়া কী, TLS-এ RSA-PSS স্বাক্ষরের সাথে ব্যবহার করা যেতে পারে।

HTTPS কানেকশনে পরিবর্তন

Android 10-এ চলা কোনও অ্যাপ setSSLSocketFactory()-এ নাল পাস করলে, IllegalArgumentException হয়। আগের ভার্সনে, setSSLSocketFactory()-এ নাল পাস করার ফলে বর্তমান ডিফল্ট ফ্যাক্টরি-তে পাস করার মতো একই প্রভাব পড়েছিল।

Android 11

SSL সকেট ডিফল্ট হিসেবে Conscrypt SSL ইঞ্জিন ব্যবহার করে

Android-এর ডিফল্ট SSLSocket প্রয়োগ Conscrypt-এর উপর ভিত্তি করে করা হয়। Android 11 থেকে, সেই ইমপ্লিমেন্টেশন ইন্টার্নালি Conscrypt-এর SSLEngine-এর উপরে তৈরি করা হয়েছে।