Linux-এ AnyConnect-এর অবৈধ TLS সংস্করণ: আগে সমাধানের পরিধি নির্ধারণ করুন

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

নীতি ছোঁয়ার আগে বার্তাটি পড়ুন

ডায়ালগ থেকে হুবহু স্ট্রিংটি সংরক্ষণ করুন। সংস্করণের অভিযোগ প্রোটোকল স্তরের দিকে, সার্টিফিকেটের অভিযোগ বিশ্বাস বা নামকরণের দিকে, আর ব্যর্থ লগইন শংসাপত্রের দিকে ইঙ্গিত করে। TLS 1.0, 1024-বিট DHE গ্রুপ, AES-256-CBC ও SHA-1 স্বাক্ষরসহ একটি গেটওয়ে পুরোপুরি বৈধ সার্টিফিকেট রাখতে পারে এবং তবুও আধুনিক নীতি আপনার শংসাপত্র পাঠানোর আগেই তা প্রত্যাখ্যান করতে পারে।

সিস্টেমের OpenSSL দিয়ে এন্ডপয়েন্টটি যাচাই করুন, প্রকৃত হোস্টনাম ও ক্লায়েন্ট যে পোর্ট ব্যবহার করে তা দিয়ে।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ব্যর্থ হয়ে -tls1 -cipher DEFAULT@SECLEVEL=0 সফল হলে বোঝা যায় সীমাটি সংস্করণ ও কী-আকার একসঙ্গে। যদি প্রথম কমান্ড প্রোটোকল সতর্কতার বদলে ছোট DH কী জানায়, সংস্করণ ঠিক আছে এবং কেবল গ্রুপটির দিকে নজর দিতে হবে। যাচাইয়ে কখনো ব্যক্তিগত কী বা পাসওয়ার্ড রাখবেন না।

বিকল্প 1: ক্রিপ্টো নীতি দিয়ে পুরো হোস্ট শিথিল করা

Fedora এবং RHEL 8 ও 9-এ update-crypto-policies --set LEGACY OpenSSL-এর সিস্টেম নীতি নামায়, আর update-crypto-policies --show কী সক্রিয় তা নিশ্চিত করে। এটি সাধারণত টানেল ফিরিয়ে আনে, কিন্তু প্রক্রিয়া চালু হওয়ার সময় নীতি পড়া হয়, তাই আবার পরীক্ষার আগে ক্লায়েন্ট ও তার তৈরি যেকোনো সহায়ক প্রক্রিয়া পুনরায় চালু করুন। এটি মেশিনের প্রতিটি TLS ক্লায়েন্টের জন্য পুরোনো প্রোটোকল ও দুর্বল গ্রুপও অনুমোদন করে — পাশের জানালার ব্রাউজার থেকে কার্নেল হালনাগাদ করা প্যাকেজ ম্যানেজার পর্যন্ত।

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

Debian ও Ubuntu-তে এর জন্য একক সুইচ নেই। সমতুল্য হলো /etc/ssl/openssl.cnf সম্পাদনা করে সিস্টেম ডিফল্ট অংশে নিম্নতর MinProtocol ও CipherString = DEFAULT@SECLEVEL=0 নির্ধারণ করা। একই পরিধি, ভিন্ন ফাইল, রিলিজ আপগ্রেডের সময় সামান্য সহজে চোখের আড়াল হওয়া।

বিকল্প 2: একজন ক্লায়েন্টের জন্য একটি কনফিগ ফাইল

প্রক্রিভিত্তিক OpenSSL কনফিগারেশন পরিবর্তনটি একটি প্রক্রিয়া-বৃক্ষের ভিতরে রাখে, তবে কেবল যদি ফাইলটি লাইব্রেরি যেভাবে আশা করে সেভাবে সংযুক্ত থাকে। ssl_conf অংশের নাম দেওয়া যথেষ্ট নয়: OpenSSL শীর্ষ-স্তরের openssl_conf কী পড়ে, সেটি অনুসরণ করে একটি ইনিট অংশে যায়, আর কেবল তখনই SSL ডিফল্টে পৌঁছায়।

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF কে সেই ফাইলের দিকে নির্দেশ করুন এবং এমন র্যাপার দিয়ে VPN ক্লায়েন্ট চালু করুন যা এটি এক্সপোর্ট করে। হোস্টের বাকি সবকিছু ডিফল্ট নীতি রাখে, আর সম্মতি-প্রশ্ন এলে এই বৈশিষ্ট্যই গুরুত্বপূর্ণ। গেটওয়েকে দোষ দেওয়ার আগে নিশ্চিত করুন ফাইলটি সত্যিই কার্যকর: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1-এ TLS 1.0 সাইফার তালিকাভুক্ত হওয়া উচিত, আর খালি ফল মানে শিকল ভেঙে গেছে এবং ক্লায়েন্ট চুপচাপ সিস্টেম ডিফল্ট রেখেছে।

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

সীমাবদ্ধতা হলো কভারেজ। GnuTLS বা NSS-এর সঙ্গে লিংক করা যেকোনো কিছু OPENSSL_CONF উপেক্ষা করে, আর ক্লায়েন্ট যে সহায়ক প্রক্রিয়াগুলো পরিবেশ উত্তরাধিকার না করেই চালায় সেগুলোও। র‍্যাপার বানানোর আগে ldd দিয়ে দেখুন বাইনারিটি আসলে কোন TLS লাইব্রেরির সঙ্গে লিংক করা, কারণ উত্তরটাই ঠিক করে এই বিকল্প আদৌ আছে কি না।

বিকল্প 3: নিষ্পত্তিযোগ্য VM বা কন্টেইনার

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

এটি এখনো একটি নেটওয়ার্কযুক্ত মেশিন, তাই এর প্রবেশাধিকার সীমিত করুন এবং সাধারণ ব্রাউজিং থেকে দূরে রাখুন। রক্ষণাবেক্ষণ ব্যয় আরেকটি প্যাচ করতে হবে এমন ইমেজ, যা বাস্তব কিন্তু সীমিত ও দৃশ্যমান — ল্যাপটপে ভুলে যাওয়া LEGACY পতাকার বিপরীতে।

তুলনাটি আপনাকে কী রেখে যায়

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

টেকসই সমাধান অ্যাপ্লায়েন্সেই: TLS 1.2 বা তার পরের, অন্তত 2048 বিটের গ্রুপ, AEAD সাইফার, এবং আধুনিক স্বাক্ষরযুক্ত সার্টিফিকেট। অ্যাপ্লায়েন্সের মালিকের কাছে সেই পরিবর্তন চান, তারপর ক্লায়েন্ট লগে সম্মত সংস্করণ ও সাইফার নিশ্চিত করুন। ব্যতিক্রমটি হোস্ট, গেটওয়ে, সম্মত প্রোটোকল, অনুমোদনকারী ও মেয়াদ শেষের তারিখসহ লিখে রাখুন, কারণ এই নোটটাই সাময়িক সমাধানকে ডিফল্ট হয়ে যাওয়া থেকে আটকায়।