নেটওয়ার্ক প্রোটোকল সহ নিরাপত্তা

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

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

ধারণা

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

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

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

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

বিশ্বস্ত CA সাধারণত হোস্ট প্ল্যাটফর্মে তালিকাভুক্ত করা হয়। অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) 100 টির বেশি 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 দ্বারা জারি করা শংসাপত্র সহ একটি ওয়েব সার্ভার রয়েছে বলে ধরে নিচ্ছি, আপনি নিম্নলিখিত কোডে দেখানো হিসাবে একটি নিরাপদ অনুরোধ করতে পারেন:

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 ডকুমেন্টেশনে অনুরোধ এবং প্রতিক্রিয়া শিরোনাম পরিচালনা, বিষয়বস্তু প্রকাশ, কুকিজ পরিচালনা, প্রক্সি ব্যবহার, প্রতিক্রিয়া ক্যাশিং এবং আরও অনেক কিছুর উদাহরণ রয়েছে৷ অ্যান্ড্রয়েড ফ্রেমওয়ার্ক এই API ব্যবহার করে সার্টিফিকেট এবং হোস্টনাম যাচাই করে।

যখনই সম্ভব এই APIs ব্যবহার করুন. নিম্নলিখিত বিভাগটি সাধারণ সমস্যাগুলিকে কভার করে যার বিভিন্ন সমাধান প্রয়োজন৷

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

ধরুন বিষয়বস্তু ফেরত দেওয়ার পরিবর্তে, 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 ইনস্টল করা যা কিছুই করে না। এটি করার ফলে আপনার ব্যবহারকারীরা পাবলিক ওয়াই-ফাই হটস্পট ব্যবহার করার সময় আক্রমণের ঝুঁকিতে পড়ে, কারণ একজন আক্রমণকারী আপনার সার্ভারের ভান করে এমন একটি প্রক্সির মাধ্যমে আপনার ব্যবহারকারীদের ট্রাফিক পাঠাতে DNS কৌশল ব্যবহার করতে পারে। আক্রমণকারী তারপর পাসওয়ার্ড এবং অন্যান্য ব্যক্তিগত ডেটা রেকর্ড করতে পারে। এটি কাজ করে কারণ আক্রমণকারী একটি শংসাপত্র তৈরি করতে পারে এবং একটি বিশ্বস্ত উত্স থেকে শংসাপত্রটি এসেছে তা যাচাই না করে একটি TrustManager ব্যতীত, আপনি এই ধরনের আক্রমণকে ব্লক করতে পারবেন না৷ তাই এটা করবেন না, এমনকি সাময়িকভাবে। পরিবর্তে, আপনার অ্যাপটিকে সার্ভারের শংসাপত্র প্রদানকারীকে বিশ্বাস করুন৷

স্ব-স্বাক্ষরিত সার্ভার শংসাপত্র

দ্বিতীয়ত, একটি স্ব-স্বাক্ষরিত শংসাপত্রের কারণে SSLHandshakeException ঘটতে পারে, সার্ভারটিকে তার নিজস্ব CA করে। এটি একটি অজানা শংসাপত্র কর্তৃপক্ষের অনুরূপ, তাই আপনার স্ব-স্বাক্ষরিত শংসাপত্রগুলিকে বিশ্বাস করতে আপনার অ্যাপ্লিকেশনের নেটওয়ার্ক নিরাপত্তা কনফিগ পরিবর্তন করুন৷

অন্তর্বর্তী সার্টিফিকেট কর্তৃপক্ষ অনুপস্থিত

তৃতীয়, মধ্যবর্তী CA অনুপস্থিত হওয়ার কারণে SSLHandshakeException ঘটে। পাবলিক CA খুব কমই সার্ভার শংসাপত্রে স্বাক্ষর করে। পরিবর্তে, রুট CA মধ্যবর্তী CA গুলি স্বাক্ষর করে।

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

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

উদাহরণস্বরূপ, এখানে 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
---

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

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

$ 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() ত্রুটির ক্ষেত্রে একটি ব্যতিক্রম নিক্ষেপ করে না। পরিবর্তে, এটি একটি বুলিয়ান ফলাফল প্রদান করে যা আপনাকে অবশ্যই স্পষ্টভাবে পরীক্ষা করতে হবে।

অবরুদ্ধ CA

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

এই ঝুঁকি প্রশমিত করার জন্য, অ্যান্ড্রয়েডের একটি অস্বীকৃত তালিকায় নির্দিষ্ট শংসাপত্র বা এমনকি সম্পূর্ণ CA যোগ করার ক্ষমতা রয়েছে। যদিও এই তালিকাটি ঐতিহাসিকভাবে অপারেটিং সিস্টেমে তৈরি করা হয়েছিল, Android 4.2 থেকে শুরু করে এই তালিকাটি ভবিষ্যতের আপস মোকাবেলা করার জন্য দূরবর্তীভাবে আপডেট করা যেতে পারে।

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

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

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

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

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

Nogotofail: একটি নেটওয়ার্ক ট্রাফিক নিরাপত্তা পরীক্ষার টুল

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

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

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

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

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

SSL এবং TLS-এ আপডেট

অ্যান্ড্রয়েড 10

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

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

উপরন্তু, একটি KeyChain অবজেক্টে কী বা CA শংসাপত্রগুলি আমদানি করতে Android 10 বা উচ্চতর ডিভাইসের স্ক্রিন লক থাকা আবশ্যক নয়৷

TLS 1.3 ডিফল্টরূপে সক্রিয়

অ্যান্ড্রয়েড 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 নিষ্ক্রিয় করা একটি SSLCcontext পেতে পারেন৷ আপনি একটি উপযুক্ত বস্তুতে setEnabledProtocols() কল করে প্রতি-সংযোগের ভিত্তিতে প্রোটোকল সংস্করণগুলি সক্ষম বা নিষ্ক্রিয় করতে পারেন।

SHA-1-এর সাথে স্বাক্ষরিত শংসাপত্রগুলি TLS-এ বিশ্বস্ত নয়৷

Android 10-এ, যে শংসাপত্রগুলি SHA-1 হ্যাশ অ্যালগরিদম ব্যবহার করে সেগুলি TLS সংযোগগুলিতে বিশ্বস্ত নয়৷ Root CA গুলি 2016 সাল থেকে এই ধরনের শংসাপত্র জারি করেনি এবং তারা আর Chrome বা অন্যান্য প্রধান ব্রাউজারে বিশ্বস্ত নয়৷

SHA-1 ব্যবহার করে একটি শংসাপত্র উপস্থাপন করে এমন একটি সাইটে সংযোগ হলে সংযোগ করার কোনো প্রচেষ্টা ব্যর্থ হয়।

কীচেইন আচরণ পরিবর্তন এবং উন্নতি

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

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

উপরন্তু, একটি KeyChain অবজেক্টে কী বা CA শংসাপত্রগুলি আমদানি করতে Android 10 বা উচ্চতর ডিভাইসের স্ক্রিন লক থাকা আবশ্যক নয়৷

অন্যান্য 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 হোস্টনাম হিসাবে বিবেচিত হয় না৷
• সার্টিফিকেট রিকোয়েস্টে সমর্থিত_স্বাক্ষর_অ্যালগরিদম এক্সটেনশনটি শংসাপত্রের প্রতিক্রিয়াগুলির জন্য একটি স্বাক্ষর কী নির্বাচন করার সময় সম্মান করা হয়।
• অস্বচ্ছ সাইনিং কী, যেমন Android কীস্টোর থেকে, TLS-এ RSA-PSS স্বাক্ষরের সাথে ব্যবহার করা যেতে পারে।

HTTPS সংযোগ পরিবর্তন

যদি Android 10 চালিত একটি অ্যাপ setSSLSocketFactory() এ নাল পাস করে, তাহলে একটি IllegalArgumentException ঘটে। পূর্ববর্তী সংস্করণগুলিতে, নালকে setSSLSocketFactory() -এ পাস করা বর্তমান ডিফল্ট কারখানায় পাস করার মতো একই প্রভাব ফেলে।

অ্যান্ড্রয়েড 11

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

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