CA ছাড়া OpenVPN: peer-fingerprint কীভাবে পিয়ার যাচাই করে
একটি ফিঙ্গারপ্রিন্ট একটি সার্টিফিকেট পিন করে, কোনো ভাগ করা গোপন নয়। ডাইজেস্ট কী ঢাকে, প্রতিটি পক্ষ কীভাবে তার অনুমোদিত তালিকা বানায় এবং নবায়নের খরচ কত—সবই দেখুন।
ছোট একটি স্থাপনা ফিঙ্গারপ্রিন্টের দিকে ঝোঁক, কারণ সার্টিফিকেট অথরিটি এমন অবকাঠামো মনে হয় যার জন্য কারও সময় নেই। প্রবৃত্তিটি যুক্তিসঙ্গত, কিন্তু মানুষ এর বদলে যে শর্টকাট নেয়—একটি ডেটা-চ্যানেলের গোপনীয়তা দুই প্রান্তে কপি করা—সেটি নয়। peer-fingerprint ব্যবস্থা TLS কাঠামো অক্ষত রাখে: প্রতিটি পক্ষ এখনও নিজের ব্যক্তিগত কী ও সার্টিফিকেট ধরে রাখে, এবং প্রতিটি পক্ষ এখনও অন্যটিকে যাচাই করে। যা বদলায় তা হলো যাচাই কোথায় নোঙর করা, একটি বিশ্বস্ত ইস্যুকারী থেকে পিন করা ডাইজেস্টের ছোট তালিকায়। যেহেতু ডাইজেস্ট পুরো সার্টিফিকেট ঢাকে, নাম নয়, তাই নবায়ন সত্যিই সময় খায় এমন কাজে পরিণত হয়।
ফিঙ্গারপ্রিন্ট আসলে কীসের দায় নেয়
সার্টিফিকেট ফিঙ্গারপ্রিন্ট হলো পুরো DER-এনকোড করা সার্টিফিকেটের ডাইজেস্ট, তার পাবলিক কী-এর নয় এবং তার সাবজেক্ট নামেরও নয়। তাই একই নাম ও একই কী কিন্তু ভিন্ন বৈধতার তারিখযুক্ত দুই সার্টিফিকেটের ফিঙ্গারপ্রিন্ট ভিন্ন হয়। এটাই পিনিংকে নির্ভুল করে, এবং এটাই নবায়নকে ব্যাঘাতময় করে। পিনিং সাধারণভাবে একটি কী-তে বিশ্বাস করা বোঝাতে পারে না, কারণ এটি তার জীবনের একটি মুহূর্তে একটি নির্দিষ্ট বস্তুর নাম বলে। যে কেউ ডাইজেস্ট জানতে পারে, আর তা জানা নিজে থেকে কিছু প্রমাণ করে না।
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256মিলে যাওয়া ব্যক্তিগত কী-এর অধিকারই প্রমাণ করে পিয়ারের কাছে সেই সার্টিফিকেট আছে, আর ডাইজেস্ট হলো অন্য পক্ষ কীভাবে সিদ্ধান্ত নেয় যে সে আদৌ সেই সার্টিফিকেট প্রত্যাশা করেছিল। এই বিচ্ছেদই কারণ এই নকশা পুরোনো ভাগ-করা-গোপন ব্যবস্থা নয়: ভাগ করা কী একই বাইট জানে এমন সবাইকে প্রমাণিত করে, পিনিং একটি সার্টিফিকেট প্রমাণিত করে। ভিন্ন ডিভাইস একই গোপনীয়তার কপি নয়, নিজের এন্ট্রি পায়—ফাইলে ছোট পার্থক্য, ক্ষতির বিস্তারে বড় পার্থক্য।
মানচিত্রটি পারস্পরিক, প্রতিসম নয়
প্রতিটি প্রান্তের দুটি জিনিস দরকার: নিজের ব্যক্তিগত কী ও সার্টিফিকেট, এবং কোন পিয়ার সার্টিফিকেট গ্রহণ করবে সে সম্পর্কে একটি বিবৃতি। ক্লায়েন্টে সেই বিবৃতি সার্ভার সার্টিফিকেটের ডাইজেস্ট; সার্ভারে তা নিবন্ধিত ক্লায়েন্ট ডাইজেস্টের তালিকা। Community 2.6-এর জন্য একটি সরকারি ছোট-স্থাপনা উদাহরণ peer-fingerprint দিয়ে বিন্যাসটি দেখায়, এবং বাস্তব স্থাপনার জন্য এই বিশ্বাস-মডেল বেছে নেওয়ার আগে এটি পড়া উচিত। দুই দিক এক তালিকার উল্টো নয়, আর তারা একই মুহূর্তে ব্যর্থ হয় না।
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
ডিভাইস যোগ করা সার্ভারে একটি অনুমোদিত তালিকা সম্পাদনা করে, বিদ্যমান ক্লায়েন্টের ব্যক্তিগত উপাদান কপি না করে এবং সার্ভার কী কোথাও সরানো ছাড়া। দুই দিক স্বতন্ত্রভাবেও ব্যর্থ হয়, যা রোগনির্ণয়ে কাজে লাগে: যে পক্ষ হ্যান্ডশেক বন্ধ করে, সেই পক্ষের প্রত্যাশাই পূরণ হয়নি। ক্লায়েন্ট সার্ভার প্রত্যাখ্যান করলে ডাইজেস্ট উপস্থাপিত সার্টিফিকেটের সঙ্গে মেলে না। সার্ভার ক্লায়েন্ট প্রত্যাখ্যান করলে সেই ক্লায়েন্টের ডাইজেস্ট তালিকায় নেই, অথবা ক্লায়েন্ট নিবন্ধিতটির বদলে অন্য সার্টিফিকেট উপস্থাপন করছে।
নিবন্ধন: নতুন ডিভাইস কীভাবে যোগ দেয়
নতুন ডিভাইসের কী ও সার্টিফিকেট যেখানে ব্যক্তিগত কী থাকবে সেখানেই তৈরি করুন, তারপর কেবল পাবলিক উপাদানটি যে পক্ষ পিন করবে তার কাছে নিন। প্রত্যাশিত ডাইজেস্ট এমন চ্যানেলে পাঠান যা আপনি আগে থেকেই বিশ্বাস করেন, এবং চেনা দেখতে নামের বদলে সম্পূর্ণ সার্টিফিকেট তুলনা করুন। সার্টিফিকেটের সঙ্গে একই অযাচাইকৃত ডাউনলোড থেকে কপি করা ডাইজেস্ট কেবল প্রমাণ করে দুটি ফাইল পরস্পরের সঙ্গে মেলে। এটি পরিচয় যাচাই নয়, সঙ্গতি যাচাই, আর এটাই এই নকশা দুর্বল হওয়ার সবচেয়ে নীরব পথ।
সার্ভারে ডাইজেস্ট যোগ করা একটি কনফিগারেশন পরিবর্তন যা স্বাভাবিক ম্যানেজারের মধ্য দিয়ে যায় এবং এর পরে পুনঃসংযোগ হয়। নিশ্চিত করুন নতুন ডিভাইস সংযোগ করছে এবং যার ডাইজেস্ট সরানো হয়েছে সেই ডিভাইস আর করছে না। কেবল ইতিবাচক ক্ষেত্র ঢাকা পরীক্ষা অনুমোদিত তালিকাকে অযাচাইকৃত রেখে দেয়, আর ছয় মাস পরে আপনি ঠিক সেই অবস্থাতেই থাকবেন।
নবায়নই ব্যয়বহুল মুহূর্ত
প্রতিটি সার্টিফিকেটের মেয়াদ শেষ হয়, এবং কী ও নাম একই থাকলেও নতুন সার্টিফিকেটের নতুন ডাইজেস্ট থাকে। ইস্যুকারীর অধীনে নবায়ন সেই ইস্যুকারীকে বিশ্বাস করা পিয়ারদের কাছে স্বচ্ছ; পিনিংয়ের অধীনে এটি সার্টিফিকেট পিন করা প্রতিটি পিয়ারের জন্য নিবন্ধন-ঘটনা।
মেয়াদ শেষের তারিখের পরে নয়, আগেই ক্রমটি পরিকল্পনা করুন। নতুন ডাইজেস্ট যারা যাচাই করে তাদের মধ্যে বিতরণ করুন, পরিবর্তন প্রয়োগ করুন, তারপরেই প্রান্তে সার্টিফিকেট বদলান। এই ক্রমে এমন কোনো জানালা থাকে না যেখানে দুই পক্ষ কোন সার্টিফিকেট চলমান তা নিয়ে দ্বিমত পোষণ করে। তালিকাটিকেও পর্যালোচনায় রাখুন, কারণ পিন করা তালিকা মাসখানেক আগে অবসর নেওয়া ডিভাইসের এন্ট্রি জমায়। প্রতিটি পুরোনো এন্ট্রি এমন পরিচয় যা তার কী টিকে থাকলে এখনও প্রমাণিত হয়, তাই একটি সরানো পরিষ্কার-পরিচ্ছন্নতা নয়, নিরাপত্তা পদক্ষেপ।
বিশ্বাস-মানচিত্র যা স্থির করে না
প্রমাণীকরণ একটি স্তর, আর পিন করা মানচিত্র ঠিকানা পুল, পুশ করা রুট, পথের MTU বা ফায়ারওয়াল নীতি নিয়ে কিছুই বলে না। এগুলো আলাদা কনফিগারেশন ও আলাদা ব্যর্থতার ধরন হয়ে থাকে। যে টানেল প্রমাণিত হয় কিন্তু কোনো ট্রাফিক চালায় না, তা কখনও না ওঠা টানেলের চেয়ে আলাদা তদন্ত।
মানচিত্রটিও অসীমভাবে স্কেল করে না, এবং বৃহত্তর স্থাপনাগুলো ইস্যুকারী-ভিত্তিক PKI-তে গিয়ে থামে। এই পছন্দ ক্রিপ্টোগ্রাফি নয়, পরিচালনা সম্পর্কে, কারণ বহর বাড়ার সঙ্গে প্রতিটি পিয়ারে তালিকা সম্পাদনার চেয়ে এক কর্তৃপক্ষের মাধ্যমে পরিচয় যোগ ও অবসর দেওয়া সস্তা। যেখানে কোনো ক্লায়েন্ট বাস্তবায়ন এই অপশন সমর্থন করে না, সেখানে উত্তর হলো সেই ক্লায়েন্টের নথিভুক্ত সামঞ্জস্যপূর্ণ বিশ্বাস-মডেল, অথবা সমর্থিত বিকল্প। যাচাইয়ের সতর্কতা চেপে রাখা সেই সমর্থন যোগ করে না, আর নকশার পুরো মূল্যই হলো যাচাই এখনও ঘটে।