সার্ভার সার্টিফিকেট চেইন কি ক্লায়েন্টের ট্রাস্ট স্টোর অগ্রাহ্য করতে পারে?

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

যাচাই চলে ক্লায়েন্টে, ক্লায়েন্টের অ্যাঙ্কর দিয়ে

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

তাই সম্পূর্ণ চেইন প্রমাণ করে সার্ভারের কাছে টুকরোগুলো আছে। এটি প্রমাণ করে না যে ক্লায়েন্ট সেগুলো গ্রহণ করবে।

সার্ভার আসলে কী পাঠায় দেখতে চালান openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts এবং আউটপুটে সার্টিফিকেটগুলো গুনুন। সেখানে অসম্পূর্ণ চেইন হলো সার্ভার-পক্ষের সংশোধন। সম্পূর্ণ চেইন প্রশ্নটি ক্লায়েন্ট ও তার অ্যাঙ্করের কাছে সরিয়ে দেয়, যেখানে সার্ভারের কোনো ভোট নেই।

TLS পরিদর্শন আসলে কী বদলায়

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

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

VPN টার্মিনেশন মানে HTTPS ডিক্রিপশন নয়

একটি VPN স্তর ক্লায়েন্ট ও গেটওয়ের মধ্যে প্যাকেট বহন করে। এটি সরানো বা তার কনফিগ পড়া ভেতরের HTTPS পেলোড প্রকাশ করে না।

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

আপনি যে উপাদান নিয়ন্ত্রণ করেন সেখানে প্রত্যাশা ঠিক করুন

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

ব্যবস্থাপিত সরঞ্জামে অসমঞ্জস্য অ্যাপ্লিকেশন ও নেটওয়ার্ক মালিকদের মাধ্যমে সমাধান করুন। যাচাই বন্ধ করা, ব্যাখ্যাহীন রুট যোগ করা বা পরিদর্শন নীতি অতিক্রমের চেষ্টা কাঙ্ক্ষিত পিয়ার সম্পর্ক প্রতিষ্ঠা করে না।

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