SSTP এবং SSL 3.0: লেবেল বনাম সম্মত সংস্করণ

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

একই প্রশ্নের দুটি উত্তর

লেবেলের যুক্তি বলা সহজ: SSTP-কে নিরাপদ সকেট টানেলিং প্রোটোকল বলা হয়, ঐতিহাসিক নাম SSL বলে, তাই সংযোগটি SSL 3.0 হতে হবে। এটি টিকে থাকে কারণ নামটি সত্যিই সেই ধারা থেকে এসেছে এবং কারণ যারা এটি পুনরাবৃত্তি করে তাদের অধিকাংশই কখনও হ্যান্ডশেক দেখেনি। এটি এই কারণেও টিকে থাকে যে সিদ্ধান্তটি সতর্ক শোনায়, যেন সবচেয়ে খারাপটা ধরে নেওয়াই নিরাপদ পছন্দ। সবচেয়ে খারাপটা ধরে নেওয়া আর প্রকৃত সংস্করণ মাপা দুটি ভিন্ন কাজ, এবং এর মধ্যে কেবল একটি কিছু বদলায়।

প্রমাণের যুক্তি আরও সংকীর্ণ প্রশ্ন করে। এই ক্লায়েন্ট ও এই সার্ভার এই প্রান্তবিন্দুতে, এই সময়ে কোন প্রোটোকল সংস্করণে সম্মত হয়েছে? উত্তর আসে সেই পরিষেবা থেকে যা TLS শেষ করে, কোনো বিপণন পৃষ্ঠা বা এমন ব্রাউজার থেকে নয় যা একই রকম নামের সাইটে পৌঁছেছে।

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

পরিষেবা সত্যিই যে সংস্করণ বেছে নেয় তা পড়ুন

উপাদানগুলোর নাম দিয়ে শুরু করুন: ক্লায়েন্ট বাস্তবায়ন, সার্ভার বাস্তবায়ন, TLS প্রান্তবিন্দু এবং মাঝখানে যা কিছু TLS শেষ করে আবার প্রতিষ্ঠা করে। একটি লোড ব্যালেন্সার যা TLS শেষ করে এবং ব্যাকএন্ডের সঙ্গে সাধারণ HTTP বলে, সেটি বদলে দেয় আপনাকে কোন ডিভাইসের নীতি পড়তে হবে।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

রেকর্ড ক্ষেত্রটিকে আলোচনা থেকে আলাদা করুন

একটি ক্ষেত্রে পুরোনো দেখানো সংস্করণ নম্বর SSL 3.0 সেশনের মতো একই তথ্য নয়। RFC 7568 রেকর্ড স্তরের সংস্করণ ও সম্মত প্রোটোকলকে আলাদা বিষয় হিসেবে দেখে, এবং ঠিক এই পার্থক্য থেকেই আত্মবিশ্বাসী ভুল উত্তর আসে। সম্মত প্রোটোকল পড়ুন, তারপর সাইফার, এবং কেবল তখনই সেশন সম্পর্কে সিদ্ধান্তে আসুন।

একই নথি প্রোটোকল সম্পর্কে স্পষ্ট: SSL 3.0 ব্যবহার করা যাবে না, এবং এতে দরকষাকষি বা ফিরে যাওয়া নিষিদ্ধ। কারণ হলো ভাঙা CBC গঠন যা POODLE আক্রমণ কাজে লাগিয়েছিল, এবং এটি প্রোটোকলের বৈশিষ্ট্য, কোনো একটি অ্যাপ্লিকেশনের কনফিগারেশন নয়।

তাই “এই কাজের চাপ সম্ভবত শোষণ করা কঠিন” SSL 3.0 সক্রিয় রাখার যুক্তি নয়। প্রয়োজন প্রোটোকল সরানো, কোনো একটি প্রদর্শনী নিয়ে তর্ক জেতা নয়।

SSL 3.0 তুলে দিন এমন নীতি দিয়ে যা আপনি সমর্থন করতে পারেন

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

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

পরিবর্তনটি নতুন সংযোগে গ্রহণ করুন

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

মনে রাখুন হ্যান্ডশেক কী ঢাকে না। SSTP, TLS স্তরের পরে PPP প্রমাণীকরণ বহন করে, তাই আধুনিক প্রোটোকল সংস্করণ কিছুই বলে না কোন ব্যবহারকারী অনুমোদিত হয়েছিল বা সেশন কোন সম্পদে পৌঁছাতে পারে। এগুলো আলাদা নিয়ন্ত্রণ আলাদা প্রমাণসহ।

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