একটি পুরোনো পিয়ার TLS 1.0 চাপিয়ে দেয়: ব্যতিক্রমের পরিধি সীমিত করুন, হোস্টের নয়

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

নির্দেশনা সম্পাদনার আগে ব্যর্থতাটি দুই ভাগে ভাগ করুন

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

দুর্বলতর ন্যূনতম সীমার সৎ জায়গা হলো দ্বিতীয় লিসেনার

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

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

পুরোনো প্রোভাইডার সার্টিফিকেট আসলে কী ভাঙে

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

ব্যানার নয়, নেগোশিয়েট হওয়া মানগুলো পড়ুন

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

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

প্রতিটি ব্যতিক্রমের একটি মালিক ও একটি তারিখ দরকার

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

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