OpenVPN-এ dh none-এর সঙ্গে RSA সার্টিফিকেট কি কাজ করতে পারে?

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

বিভ্রান্তি সাধারণত একটি মাইগ্রেশন গাইডের সঙ্গে আসে। সেটি বলে DH প্যারামিটার ফাইলটিকে dh none দিয়ে প্রতিস্থাপন করতে, পাঠক লক্ষ করেন সার্টিফিকেটটি উপবৃত্তীয়-বক্র সার্টিফিকেট নয়, এবং দুটি তথ্যকে পরস্পরবিরোধী হিসেবে ধরা হয়।

দুটো সেটিং কেন সম্পর্কিত মনে হয়

OpenVPN-এর পুরোনো কনফিগারেশন একটি DH প্যারামিটার ফাইল চাইত, কারণ সসীম-ক্ষেত্র Diffie-Hellman-এর জন্য এমন ডোমেইন প্যারামিটার দরকার যা দুই পক্ষই একমত হয়। dh নির্দেশটি সেই ফাইলকে নির্দেশ করত। যখন কোনো স্থাপনা ECDH-তে যায়, প্যারামিটারগুলো তার বদলে একটি নামকৃত বক্র থেকে আসে, আর ফাইলটির আর দরকার হয় না, যা dh none প্রকাশ করে।

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

নামকরণটি ওভারল্যাপ আরও খারাপ করে। উপবৃত্তীয় বক্র ECDHE ও ECDSA উভয় স্যুট নামেই দেখা যায়, তাই ধরে নেওয়া সহজ যে বক্রের কথা বলা যেকোনো সংযোগে বক্র সার্টিফিকেট থাকতেই হবে। তা নয়।

TLS 1.2 স্যুট নাম সঠিকভাবে পড়া

ECDHE-RSA-AES256-GCM-SHA384 নিন। প্রথম টোকেনটি কী-বিনিময় পরিবার: ক্ষণস্থায়ী উপবৃত্তীয়-বক্র Diffie-Hellman। দ্বিতীয়টি প্রমাণ পরিবার: RSA। বাকিটা রেকর্ড সুরক্ষা এবং হ্যান্ডশেকে ব্যবহৃত হ্যাশ বর্ণনা করে।

ECDHE-ECDSA স্যুট একই কী-বিনিময় পরিবার ভিন্ন প্রমাণ পদ্ধতিতে ব্যবহার করে, তাই এর উপবৃত্তীয়-বক্র সার্টিফিকেট দরকার। DHE-RSA স্যুট RSA প্রমাণসহ সসীম-ক্ষেত্র ক্ষণস্থায়ী Diffie-Hellman ব্যবহার করে, আর ওটির সত্যিই DH প্যারামিটার দরকার।

স্যুট নাম বাঁ থেকে ডানে পড়ুন এবং প্রতিটি অংশকে তার কাজে বরাদ্দ করুন। টোকেনগুলো আলাদা হয়ে গেলে প্রশ্নটি বদলে যায়: «আমার সার্টিফিকেট কি dh none-এর সঙ্গে মেলে» থেকে «আমার সার্ভার কি এমন স্যুট অনুমোদন করে যার কী-বিনিময়ে DH ফাইল দরকার হয় না»।

dh none আসলে কী নিষ্ক্রিয় করে

dh none সার্ভারকে বলে সসীম-ক্ষেত্র DH প্যারামিটার ফাইল লোড না করতে। এটি প্রমাণ, সার্টিফিকেট যাচাই বা TLS নিজেকে নিষ্ক্রিয় করে না। এটি দাবি করে যে সম্মত হওয়া কী-বিনিময়ে সেই প্যারামিটারগুলোর দরকার না হয়, যার বাস্তব অর্থ একটি ECDHE স্যুট বা TLS 1.3 হ্যান্ডশেক।

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

উপবৃত্তীয়-বক্রের দিকে, বক্রটি সার্ভারের TLS কনফিগারেশন বেছে নেয়, এবং OpenVPN পুরোনো শাখায় এটি বেছে নেওয়ার একটি অপশন দেয়। TLS 1.3 গ্রুপ সম্মতি প্রোটোকলের ভেতরেই সামলায় এবং DH ফাইলে একেবারেই তাকায় না।

dh none নিজে থেকে নিরাপত্তার অবনমন নয়। বিনিময়ের শক্তি তখন নির্ভর করে যে বক্র ও স্যুট প্রকৃতপক্ষে সম্মত হয়েছে তার উপর, তাই পরবর্তী ধাপ হলো অনুপস্থিত ফাইলের দিকে নয়, পক্ষগুলো কী বেছে নিয়েছে তা দেখা।

সম্পাদনার আগে সম্মতি নিশ্চিত করা

সার্ভার ও ক্লায়েন্টের ভার্বোসিটি বাড়ান এবং সংযোগের পরে OpenVPN যে কন্ট্রোল-চ্যানেল লাইনটি ছাপে তা পড়ুন। এটি TLS সংস্করণ ও সম্মত সাইফারের নাম বলে এবং সহকর্মী সার্টিফিকেটের কী ধরন জানায়। ওই এক লাইনই সেই প্রশ্নের উত্তর দেয় যা কনফিগারেশন ফাইল কেবল ইঙ্গিত করে।

যদি এটি TLS 1.2-এর সঙ্গে ECDHE-RSA স্যুট ও RSA সার্টিফিকেট দেখায়, তবে সমন্বয়টি ঠিক যা dh none প্রত্যাশা করে, এবং মেরামত করার কিছু নেই। যদি এটি DHE স্যুট বা সাধারণ সাইফার ছাড়া হ্যান্ডশেক ব্যর্থতা দেখায়, তবে সমাধান সাইফার নীতিতে বা ক্লায়েন্টের সামর্থ্যে, সার্টিফিকেটে নয়।

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

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

চেকলিস্ট: সার্টিফিকেটটি কি RSA, একটি ECDHE স্যুট কি অনুমোদিত, লগ কি সেই স্যুট দেখায়, এবং সবচেয়ে পুরোনো সমর্থিত ক্লায়েন্টও কি তা সম্মত হয়? যদি চারটিই হ্যাঁ হয়, তবে dh none তার কাজ করছে।