VPN-এর উপর নির্ভর না করে অ্যান্ড্রয়েড অ্যাপে ক্লিয়ারটেক্সট ব্লক করুন

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

এক নামে দুটি সমস্যা

প্রথম সমস্যাটি পেলোড: অ্যাপটি শংসাপত্র বা টোকেন এমন একটি অনুরোধে লেখে যা এন্ড-টু-এন্ড এনক্রিপ্টেড নয়, তাই যে কোনো হপ যা তা দেখতে পায়, তা পড়তে পারে। দ্বিতীয়টি পথ: অ্যাপটি সম্পূর্ণ সুশৃঙ্খল হতে পারে, তবুও আপনি চান স্থানীয় Wi-Fi অপারেটর যেন এটি কোথায় সংযোগ করে তা কিছুই না জানুক। VPN দ্বিতীয়টির সমাধান করে এবং কেবল দ্বিতীয়টির।

এই পার্থক্যই ঠিক করার মালিক নির্ধারণ করে। পেলোড তার, যে অ্যাপটি বিতরণ করে, কারণ শুধু সেই কোডই ঠিক করে কোন URL ডাকা হয় এবং শংসাপত্র যাচাই হয় কি না। পথ ডিভাইস বা নেটওয়ার্কের, কারণ এটি নিয়ে যে প্যাকেট কোথায় যায়, কী বহন করে তা নিয়ে নয়।

প্রথম পথ: যে অ্যাপ আপনি নিয়ন্ত্রণ করেন

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

অ্যান্ড্রয়েড 7.0 ও তার পরে Network Security Configuration নীতিটি প্রকাশ করে। নিচের ফাইলটি সবচেয়ে ছোট কার্যকর সংস্করণ: কোনো ডোমেইন-নির্দিষ্ট ব্যতিক্রম অন্যথা না বললে এটি সর্বত্র ক্লিয়ারটেক্সট প্রত্যাখ্যান করে।

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

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

সংস্করণের দুটি বিবরণ জানা ভালো। API 28 বা তার পরে লক্ষ্য করা অ্যাপগুলো ইতিমধ্যেই ডিফল্টভাবে ক্লিয়ারটেক্সট প্রত্যাখ্যান করে, তাই যে অ্যাপ এখনো সাধারণ HTTP-তে কথা বলে সেটি হয় পুরনো API স্তর লক্ষ্য করছে, নয়তো কোথাও একটি ব্যতিক্রম আছে। আর যখন নেটওয়ার্ক সিকিউরিটি কনফিগ উপস্থিত থাকে, পুরনো android:usesCleartextTraffic ম্যানিফেস্ট অ্যাট্রিবিউট আর প্রশ্নটি নির্ধারণ করে না, তাই ওই ফ্ল্যাগ বদলালে মাঝে মাঝে কিছুই হচ্ছে না বলে মনে হয়।

দ্বিতীয় পথ: যে অ্যাপ আপনি নিয়ন্ত্রণ করেন না

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

নেটওয়ার্ক নিয়ম দেখতে যতটা শক্ত, ততটা নয়। কেবল পোর্ট 443 অনুমোদন করা প্রমাণিত TLS বলবৎ করে না, কারণ অনেক প্লেইনটেক্সট প্রোটোকল ওই পোর্টে সরানো যায়, আর পোর্ট 80 ব্লক করা অন্য পোর্টের ক্লিয়ারটেক্সট ঢাকে না। ব্রাউজারের শুধু-HTTPS মোডও ওই ব্রাউজারেই সীমিত, একই ফোনের আলাদা মেইল বা চ্যাট অ্যাপে নয়।

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

VPN কোথায় সাহায্য করে আর কোথায় করে না

যখন প্রয়োজন হয় স্থানীয় নেটওয়ার্ক সংযোগ সম্পর্কে কিছুই না জানুক, অথবা অ্যাপটি এমন একটি ব্যক্তিগত সেবায় পৌঁছাক যেখানে অন্যভাবে পৌঁছানো যায় না, তখন টানেল সঠিক হাতিয়ার। একটি HTTP ক্লায়েন্টকে HTTPS-এ কথা বলানোর জন্য এটি ভুল হাতিয়ার, কারণ অনুরোধটি টানেলে ঢুকেছিল ঠিক যেমন, তেমনি বেরিয়েও যায়।

অ্যান্ড্রয়েড একটি বাস্তব সীমাবদ্ধতা যোগ করে: প্ল্যাটফর্ম একসঙ্গে একটি VPN সেবা চালায়. ওই স্থানটি নেওয়া একটি স্থানীয় ফিল্টারিং অ্যাপ আপনার সত্যিই প্রয়োজনীয় দূরবর্তী টানেলের সঙ্গে প্রতিযোগিতা করে, আর এদের মধ্যে বদল করা অ্যাপ-স্তরের নয়, ডিভাইস-স্তরের কাজ। ওই একক স্থানই পেলোড নীতি অ্যাপে রাখার এবং পথের জন্য টানেল রাখার ভালো কারণ।

একমাত্র ক্ষেত্রে দুটি মেলে, তা হল আপনার নিজের পরিচালিত একটি ব্যক্তিগত সার্ভার। সেখানে টানেল পথটিকে ব্যক্তিগত করতে পারে, যদিও প্রোটোকল এখনো ক্লিয়ারটেক্সট, যা এক্সপোজার কমায় কিন্তু পেলোড কী তা বদলায় না। এটিকে ঝুঁকি হ্রাস হিসেবে দেখুন, ডেটার এনক্রিপশন হিসেবে নয়।

ব্লক করা বলায়ার আগে কী পরীক্ষা করবেন

মানুষকে অবাক করা ডিফল্ট দিয়ে শুরু করুন: API 28 বা তার পরে লক্ষ্য করা অ্যাপের ইতিমধ্যেই ক্লিয়ারটেক্সট প্রত্যাখ্যান করা উচিত, তাই ডিফল্টের নকল করে এমন কনফিগারেশন যোগ করার আগে লক্ষ্য স্তরটি দেখুন। তারপর ব্যর্থতার ঘটনাটি ইচ্ছাকৃতভাবে পরীক্ষা করুন: সাধারণ HTTP হোস্টে একটি অনুরোধ অবশ্যই ব্যর্থ হবে, ফলব্যাক দিয়ে চুপচাপ সফল হবে না।

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

সফলতার ক্ষেত্রে নিশ্চিত করুন যে HTTPS কলটি সত্যিকারের শংসাপত্র শৃঙ্খল যাচাই করে এবং অবিশ্বস্ত শংসাপত্রযুক্ত প্রক্সি সহ্য না করে প্রত্যাখ্যাত হয়। যে হ্যান্ডশেক যেকোনো শংসাপত্রের সঙ্গে সফল হয়, তা পরিবহন নিরাপত্তা সম্পর্কে কিছুই প্রমাণ করেনি।

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