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

প্রোফাইলে আসলে কী থাকে

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

ObjectWhere it livesWhat can open itWhat a leak costs
Server wrapping keyaccepting servers onlythe unwrap step inside the serverevery wrapped copy issued to that group becomes readable
Wrapped client keyinside the client profilethe server wrapping keyit names a client and exposes its metadata, but not the key inside
Client control keyinside the client profile, usable as-isthe client that owns itsomeone can open handshakes as that client until the server refuses the key

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

কেন মোড়ানো কপিই পুরো গল্প নয়

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

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

হ্যান্ডশেকে যাচাইকরণ হুক কোথায় বসে

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

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

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

এই দুটি লাইনই সার্ভারে নীতির পৃষ্ঠ: একটি মোড়ানোর কী-এর নাম বলে, অন্যটি প্রতিটি ক্লায়েন্টের বিচার করা প্রোগ্রামের নাম বলে। আকর্ষণীয় সবকিছু স্ক্রিপ্টেই থাকে, যা সংস্করণ নিয়ন্ত্রণ এবং অন্য যেকোনো অ্যাক্সেস নিয়মের মতোই পর্যালোচনার দাবি রাখে।

অ্যাকাউন্ট, সার্টিফিকেট ও নিয়ন্ত্রণ কী আলাদাভাবে অবসরে যায়

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

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

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

প্রোফাইল ইস্যু ও প্রত্যাহার

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

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

প্রোফাইলের মেটাডেটা সেই নীতির একটি ইনপুট, অ্যাক্সেস নিয়ন্ত্রণ ইতিমধ্যে আছে তার প্রমাণ নয়। OpenVPN 2.6 নকশা নথি বস্তুগুলো এবং তারা যে সীমা টানে তা বর্ণনা করে, আর তা প্রয়োগ করা অপারেটরের দায়িত্বেই থাকে।

সম্পর্কিত নিবন্ধ