HTTPS প্রক্সি লেবেলটি কেবল আপনার ক্লায়েন্ট ও প্রক্সির মধ্যকার পরিবহন বর্ণনা করে, এর বেশি কিছু নয়। এটি বলে না যে এর পেছনের ওয়েবসাইটটি ঐ সংযোগেই এনক্রিপ্ট করা, আর এটিও বলে না যে প্রক্সি পৃষ্ঠাটি পড়তে পারে। দুটি সংযোগ আলাদা করলেই সার্টিফিকেট ত্রুটি রহস্যময় থাকা বন্ধ করে এবং VPN-এর সঙ্গে তুলনা বাস্তব হয়ে ওঠে।

দুটি প্রান্তজোড়া, দুটি যাচাই

সাধারণ টানেল মোডে দুটি TLS সম্পর্ক থাকে। প্রথমটি আপনার ক্লায়েন্ট থেকে প্রক্সি পর্যন্ত চলে এবং প্রক্সিকে প্রমাণীকরণ করে। দ্বিতীয়টি আপনার ক্লায়েন্ট থেকে টানেলের ভেতরের ওয়েবসাইট পর্যন্ত চলে এবং ওয়েবসাইটটিকে প্রমাণীকরণ করে। এারা স্বাধীনভাবে ব্যর্থ হয় এবং স্বাধীনভাবে কনফিগার হয়।

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

এদের এমন দুটি সংযোগ হিসেবে দেখুন যারা কেবল একটি সকেট ভাগ করে, কারণ এারা ঠিক তাই।

CONNECT আসলে কী টানেল করে

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

এই পার্থক্যই টানেল মোডের সম্পূর্ণ নিরাপত্তা যুক্তি, এবং এটিই তার সীমাও।

প্রক্সি হপে TLS ছাড়া একটি HTTP প্রক্সি তবুও CONNECT দিয়ে একটি HTTPS ওয়েবসাইট বহন করে। ক্লায়েন্ট-থেকে-প্রক্সি বিনিময় খোলা থাকে, কিন্তু ওয়েবসাইট সংযোগ থাকে না, আর পুরো ব্যাপারটিকে HTTPS প্রক্সি বলা ঐ পার্থক্যটি লুকায়।

কোন সার্টিফিকেট ব্যর্থ হলো

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

curl ঠিক এই কারণেই অপশনগুলো আলাদা রাখে। প্রক্সি CA ফাইল প্রক্সির যাচাই কনফিগার করে, আর CA ফাইল সার্ভারের যাচাই কনফিগার করে, এবং প্রযোজ্য ট্রাস্ট স্টোরের আচরণও নির্ভর করে curl কীভাবে তৈরি হয়েছে তার উপর।

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

যাচাই চেপে দেওয়া কোনো মেরামত নয়। এটি দুই প্রান্তের কোনোটির সম্পর্কেই কিছু প্রমাণ করে না।

পরিদর্শন একটি ভিন্ন বন্দোবস্ত

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

আপনার ট্রাস্ট স্টোরে থাকা সংস্থাগত CA আপনি কোন বন্দোবস্তে আছেন তার একটি ইঙ্গিত, প্রমাণ নয়। সার্টিফিকেট চেইন থেকে অনুমান করার বদলে নকশাটি জিজ্ঞেস করুন।

এই দুটি বন্দোবস্ত কে পৃষ্ঠাটি পড়তে পারে সেই প্রশ্নে ভিন্ন উত্তর দেয়।

একই চারটি লাইনে প্রক্সি ও VPN তুলনা করুন

দুটি স্থাপনাকে একইভাবে বর্ণনা করলেই তুলনাটি কাজে লাগে।

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

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

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

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