HTTPS মৌলিক প্রমাণীকরণ বনাম IPsec: প্রতিটি আসলে কী রক্ষা করে

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

চেকপয়েন্ট এক: আপনি কি এই সার্ভারের সাথেই কথা বলতে চেয়েছিলেন

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

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

চেকপয়েন্ট দুই: 401 বিনিময়ে আসলে কী ভ্রমণ করে

HTTP Basic প্রমাণীকরণ ব্যবহারকারী শনাক্তকারী এবং পাসওয়ার্ড একটি হেডারে পাঠায়, Base64 দিয়ে এনকোড করা, যেমনটি বর্ণনা করা হয়েছে RFC 7617-এ। Authorization: Basic dXNlcjpwYXNz হলো আকৃতি; এনকোডিং যে কেউ অনুরোধটি পড়তে পারে তার দ্বারা উল্টানো যায়, তাই সমস্ত গোপনীয়তা নিচের পরিবহন থেকে আসে। curl -v উভয় WWW-Authenticate: Basic চ্যালেঞ্জ এবং আপনি ফেরত পাঠানো হেডার দেখায়।

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

সেই পথে IPsec টানেল কোথায় বসে

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

নির্বাচনটি হলো সেই অংশ যা মানুষকে হোঁচট খাওয়ায়। নীতি-ভিত্তিক টানেল ট্রাফিক সিলেক্টর ব্যবহার করে, প্রায়ই অ্যাক্সেস কন্ট্রোল লিস্ট হিসেবে প্রকাশ করা হয়, কোন প্যাকেট টানেলে প্রবেশ করবে তা নির্ধারণ করতে। রুট-ভিত্তিক টানেল এর বদলে একটি ভার্চুয়াল ইন্টারফেস এবং রাউটিং টেবিল ব্যবহার করে। Linux-এ ip xfrm policy সিলেক্টরগুলো দেখায় এবং ip xfrm state প্রতিষ্ঠিত নিরাপত্তা অ্যাসোসিয়েশনগুলো দেখায়; ফায়ারওয়াল অ্যাপ্লায়েন্সে সমতুল্য হলো টানেলের SA টেবিল প্লাস একটি প্যাকেট ট্রেসার।

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

যে স্তরটি ব্যর্থতার কথা জানিয়েছে সেই স্তরেই সেটি পড়ুন

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

প্রতিটি স্তর যে প্রমাণ উৎপন্ন করে তা ব্যবহার করুন: স্ট্যাটাস ও হেডারের জন্য ব্রাউজারের নেটওয়ার্ক প্যানেল, সার্টিফিকেট চেইনের জন্য openssl s_client -connect host:443, টানেল ট্রাফিকের জন্য গেটওয়ের SA কাউন্টার ও লগ, এবং অ্যাকাউন্ট সিদ্ধান্তের জন্য অ্যাপ্লিকেশন লগ। যখন দুই স্তর একসাথে ত্রুটি জানায়, প্রথমে নিচেরটি ঠিক করুন, কারণ একটি মৃত টানেল সহজেই প্রমাণীকরণ ব্যর্থতা ঢেকে দিতে পারে এবং উল্টোটাও।

একটি পরিষেবা শুরু থেকে শেষ পর্যন্ত ম্যাপ করুন

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

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

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