VPN সার্টিফিকেট অথরিটি প্রতিস্থাপন করলে কী ঘটে

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

এক প্রতিস্থাপন, দুটি আলাদা পরিবর্তন

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

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

ভ্যালিডেটর কী যাচাই করে, কোন ক্রমে

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

এই ধাপচক্র অফলাইনে পুনরাবৃত্তি করতে, -CAfile-কে সিস্টেম স্টোরের বদলে আপনি যে বান্ডল ডিপ্লয় করবেন ঠিক সেটির দিকে নির্দেশ করুন। নইলে আপনি পরিবর্তন নয়, হোস্ট পরীক্ষা করছেন:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

এই কমান্ডটি কেবল গেটওয়ের HTTPS অ্যাডমিন পেজের মতো সাধারণ TLS লিসেনারের বিরুদ্ধে কাজ করে; OpenVPN-এর কন্ট্রোল চ্যানেল TLS-এর আগে আসে, তাই s_client টানেলের হ্যান্ডশেক পরীক্ষা করতে পারে না।

ওই ত্রুটিগুলোর পেছনের পাথ-বিল্ডিং নিয়ম রয়েছে RFC 5280 ধারা 6-এ। সেগুলো ব্যাখ্যা করে সেই ব্যর্থতাগুলো যা নইলে এলোমেলো মনে হয়: কেউ মনে না রাখা একটি মেয়াদোত্তীর্ণ মধ্যবর্তী সার্টিফিকেট, যে সার্টিফিকেটের কী ব্যবহার সই নিষিদ্ধ করে, বা এমন নাম সীমাবদ্ধতা যা আপনার পরীক্ষাধীন হোস্ট বাদ দেয়।

পুরোনো টানেল কেন কাজ করতে থাকে

TLS আর OpenVPN দুটোই হ্যান্ডশেক শেষ হওয়ার পর প্রতিষ্ঠিত সেশন জীবিত রাখে। কোনো কিছু প্রতি প্যাকেটে পিয়ার সার্টিফিকেট পুনরায় যাচাই করে না, তাই পরিবর্তনের আগে সংযুক্ত ক্লায়েন্ট পুনরায় দরকষাকষি, পুনঃসংযোগ বা টানেল পড়ে যাওয়ার আগ পর্যন্ত ট্রাফিক পার করে চলে। এই ফাঁকই CA প্রতিস্থাপনকে এক ঘণ্টা ঠিক দেখিয়ে সবচেয়ে খারাপ মুহূর্তে ব্যর্থ করার কারণ: ল্যাপটপ ঘুম থেকে ওঠে, NAT ম্যাপিংয়ের সময় শেষ হয়, গেটওয়ে রিস্টার্ট হয়।

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

স্ট্যাটিক-কী স্তরটি এর থেকে আলাদা রাখুন। tls-auth কন্ট্রোল চ্যানেলে HMAC যোগ করে, tls-crypt তা এনক্রিপ্ট ও প্রমাণীকরণ করে, এবং কোনোটিই সার্টিফিকেট উপাদান বহন করে না, তাই যেকোনোটির রোটেশন নিজস্ব ব্যর্থতা-ধরনসহ আলাদা পরিবর্তন। যে ডিপ্লয়মেন্ট দুটোকে মিশিয়ে ফেলে, তাদের ক্লায়েন্টের স্ট্যাটিক কী ঠিক থাকে, সার্টিফিকেট পুরোনো হয়ে যায়, আর ত্রুটি বার্তায় কোনোটিরই উল্লেখ থাকে না।

সাবজেক্ট নাম পুনর্ব্যবহারের ফাঁদ

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

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

যে রোলওভার নেটওয়ার্ক নামায় না

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

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

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

ফাইলের তালিকা নয়, ফলাফল যাচাই করুন

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

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

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