HTTPS ও TLS আসলে কীভাবে কাজ করে: হ্যান্ডশেক ব্যাখ্যা

আপনি একটি সার্টিফিকেট যোগ করেছেন, ব্রাউজারে প্যাডলক দেখাচ্ছে, এবং আপনি এগিয়ে গেছেন। তারপর একদিন একটি API ক্লায়েন্ট SSL_ERROR_RX_RECORD_TOO_LONG ত্রুটি নিয়ে ব্যর্থ হয়, একটি মোবাইল অ্যাপ আপনার চেইন প্রত্যাখ্যান করে, অথবা HSTS সক্রিয় করার পর একটি রিডাইরেক্ট লুপ দেখা দেয়। হঠাৎ HTTPS একটি ব্ল্যাক বক্স মনে হতে শুরু করে।

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

HTTPS আসলে কী

HTTPS কোনো আলাদা প্রোটোকল নয়। এটি TLS-এনক্রিপ্টেড সংযোগের মাধ্যমে পাঠানো সাধারণ HTTP। URL স্কিম পরিবর্তিত হয়, ডিফল্ট পোর্ট 80 থেকে 443-এ চলে যায়, এবং বাকি সবকিছু — মেথড, হেডার, স্ট্যাটাস কোড, কুকি — একইভাবে কাজ করে।

TLS টিসিপি-র উপরে তিনটি নিশ্চয়তা দেয়:

• গোপনীয়তা — মাঝখানের কোনো পক্ষ ট্রাফিক পড়তে পারে না।
• অখণ্ডতা — ট্রানজিটে টেম্পারিং সনাক্ত হয়।
• প্রমাণীকরণ — ক্লায়েন্ট যাচাই করতে পারে যে এটি ডোমেইনের মালিক সার্ভারের সাথে কথা বলছে।

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

TLS 1.3 হ্যান্ডশেক, ধাপে ধাপে

TLS 1.3 TLS 1.2-এর তুলনায় হ্যান্ডশেক অনেক সরল করেছে। ব্রাউজার ও সার্ভারের মধ্যে প্রবাহটি এরকম:

1. ClientHello — ক্লায়েন্ট সমর্থিত TLS সংস্করণ, সাইফার স্যুট, একটি র‍্যান্ডম মান, এবং একটি ডিফি-হেলম্যান গ্রুপের (যেমন X25519) জন্য কী শেয়ার পাঠায়।
2. ServerHello — সার্ভার একটি সাইফার স্যুট বেছে নেয় এবং নিজের কী শেয়ার পাঠায়। এখন উভয় পক্ষ একই শেয়ার্ড সিক্রেট তৈরি করতে পারে।
3. এনক্রিপ্টেড এক্সটেনশন ও সার্টিফিকেট — সার্ভার তার সার্টিফিকেট চেইন পাঠায়, যা ইতিমধ্যে প্রাপ্ত কী দিয়ে এনক্রিপ্ট করা।
4. Finished — উভয় পক্ষ হ্যান্ডশেক ট্রান্সক্রিপ্টের উপর একটি MAC পাঠায় যাতে প্রমাণ হয় কিছুই টেম্পার হয়নি।
5. অ্যাপ্লিকেশন ডেটা — HTTP অনুরোধ ও প্রতিক্রিয়া প্রতিষ্ঠিত সেশনের উপর প্রবাহিত হয়।

TLS 1.3-এ সম্পূর্ণ হ্যান্ডশেকে এক রাউন্ড ট্রিপ লাগে, এবং রিজিউমশনে শূন্য রাউন্ড ট্রিপে পৌঁছানো সম্ভব। TLS 1.2-এ কোনো অ্যাপ্লিকেশন ডেটা প্রবাহিত হওয়ার আগে দুই রাউন্ড ট্রিপ লাগত।

কী তৈরি হওয়ার পর কেন সার্টিফিকেট পাঠানো হয়

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

সিমেট্রিক বনাম অ্যাসিমেট্রিক এনক্রিপশন

একটি সাধারণ ভুল ধারণা হল HTTPS সবকিছু সার্ভারের পাবলিক কী দিয়ে এনক্রিপ্ট করে। আসলে তা নয়। অ্যাসিমেট্রিক ক্রিপ্টোগ্রাফি ধীর এবং আকারে সীমিত; এটি শুধু একটি শেয়ার্ড সিক্রেট প্রতিষ্ঠা করতে ব্যবহৃত হয়।

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

সার্টিফিকেটের ভেতরে কী থাকে

একটি X.509 সার্টিফিকেট একটি পাবলিক কী-কে একটি ডোমেইন নামের সাথে বেঁধে দেয়। এতে থাকে:

• সাবজেক্ট (ডোমেইন) এবং সাবজেক্ট অল্টারনেটিভ নেম (SAN), যা ব্রাউজার আসলে যাচাই করে।
• পাবলিক কী এবং তার অ্যালগরিদম।
• বৈধতার সময়কাল।
• ইস্যুয়ার এবং সেই ইস্যুয়ারের স্বাক্ষর।

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

ব্যবহারিক ডিবাগিং ধাপ

যখন HTTPS সমস্যা করে, বাইরে থেকে ভেতরে কাজ করুন।

1. চেইন যাচাই করুন openssl s_client -connect example.com:443 -servername example.com -showcerts দিয়ে। নিশ্চিত করুন সার্ভার সম্পূর্ণ চেইন পাঠাচ্ছে, শুধু লিফ নয়।
2. মেয়াদ যাচাই করুন — মেয়াদোত্তীর্ণ সার্টিফিকেট কোনো সমাধান ছাড়াই কঠিন ব্যর্থতা তৈরি করে।
3. হোস্টনেম যাচাই করুন — SAN তালিকায় ক্লায়েন্ট যে নির্দিষ্ট হোস্টনেম অনুরোধ করছে তা থাকতে হবে, যেকোনো www প্রিফিক্সসহ।
4. প্রোটোকল সংস্করণ যাচাই করুন — যদি কোনো লিগ্যাসি ক্লায়েন্ট শুধু TLS 1.0 সমর্থন করে এবং আপনার সার্ভার TLS 1.2+ প্রয়োজন করে, তাহলে HTTP-এর আগেই হ্যান্ডশেক ব্যর্থ হয়।
5. রিডাইরেক্ট যাচাই করুন — HTTPS থেকে HTTP-তে এবং আবার ফিরে রিডাইরেক্ট একটি লুপ তৈরি করে; এটি সার্ভার কনফিগে ঠিক করুন, অ্যাপ্লিকেশন কোডে নয়।

# Inspect the certificate chain and negotiated protocol
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts < /dev/null 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

# Test a specific TLS version
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

Nginx-এ, ssl_certificate ডিরেক্টিভটি এমন একটি ফাইলে নির্দেশ করা উচিত যাতে লিফ সার্টিফিকেটের পরে ইন্টারমিডিয়েট থাকে, সেই ক্রমে। ভুল ক্রমে সেগুলো একত্রিত করলে চেইন ত্রুটি তৈরি হয় যা সহজে চোখে পড়ে না।

HSTS এবং ভুল করার মূল্য

HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি ব্রাউজারকে নির্দিষ্ট সময়ের জন্য একটি ডোমেইনে HTTPS ব্যবহার করতে বলে। এটি শক্তিশালী এবং ক্ষমাশীল নয়: একবার ব্রাউজার একটি দীর্ঘ max-age দেখে ফেললে, আপনি পরে সার্ভারে HTTPS নিষ্ক্রিয় করলেও এটি সাধারণ HTTP প্রত্যাখ্যান করবে।

একটি ছোট max-age দিয়ে শুরু করুন, সবকিছু কাজ করছে যাচাই করুন, তারপর বাড়ান। includeSubDomains শুধু তখনই যোগ করুন যখন প্রতিটি সাবডোমেইন বৈধ HTTPS পরিবেশন করে। প্রিলোডিং কার্যত স্থায়ী — শুধু নিশ্চিত হলে অনুরোধ করুন।

সাধারণ ভুল কনফিগারেশন

• মিক্সড কনটেন্ট — একটি HTTPS পেজ HTTP-এর মাধ্যমে স্ক্রিপ্ট বা ছবি লোড করছে। ব্রাউজার সক্রিয় মিক্সড কনটেন্ট ব্লক করে এবং নিষ্ক্রিয় কনটেন্টে সতর্ক করে।
• দুর্বল সাইফার স্যুট — আর প্রয়োজন নেই এমন সামঞ্জস্যের জন্য CBC-মোড সাইফার এবং পুরনো প্রোটোকল সংস্করণ সক্রিয় রাখা।
• OCSP বা CRL হ্যান্ডলিং অনুপস্থিত — বাস্তবে রিভোকেশন চেকিং অবিশ্বাসযোগ্য; স্বল্পমেয়াদী সার্টিফিকেট বেশি নির্ভরযোগ্য সমাধান।
• সার্টিফিকেট অটোমেশন ফাঁক — নবায়ন কাজ করে, কিন্তু সার্ভারকে নতুন সার্টিফিকেট গ্রহণ করানোর রিলোড ধাপটি অনুপস্থিত।

সার্টিফিকেট নবায়নকে একটি ডেপ্লয়মেন্ট পাইপলাইন হিসেবে বিবেচনা করুন, ক্যালেন্ডার রিমাইন্ডার হিসেবে নয়। যদি নবায়নের জন্য মানুষের প্রয়োজন হয়, তাহলে এটি সবচেয়ে খারাপ সময়ে ব্যর্থ হবে।

সাধারণ প্রশ্ন

HTTPS কি আমি যে ডোমেইনে যাই তা এনক্রিপ্ট করে?

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

কেন আমার সাইট ব্রাউজারে কাজ করে কিন্তু curl বা মোবাইল অ্যাপে ব্যর্থ হয়?

প্রায় সবসময়ই একটি অনুপস্থিত ইন্টারমিডিয়েট সার্টিফিকেট। ব্রাউজার প্রায়ই পূর্ববর্তী ভিজিট থেকে ইন্টারমিডিয়েট ক্যাশ করে, যেখানে curl এবং অনেক মোবাইল HTTP স্ট্যাক সার্ভারকে সম্পূর্ণ চেইন পাঠাতে বাধ্য করে।

TLS 1.3 কি সবসময় TLS 1.2-এর চেয়ে ভালো?

আধুনিক ক্লায়েন্টের জন্য, হ্যাঁ — কম রাউন্ড ট্রিপ, ছোট সাইফার স্যুট সেট, এবং ডিফল্টভাবে ফরওয়ার্ড সিক্রেসি। TLS 1.2 শুধু তখনই সক্রিয় রাখুন যখন আপনার কাছে এমন ক্লায়েন্ট থাকে যারা 1.3 নেগোশিয়েট করতে পারে না।

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