TLS/SSL Handshake
- ●TLS data-কে encrypt করে যাতে মাঝপথে কেউ পড়তে বা বদলাতে না পারে — এটাই HTTPS-এর S।
- ●Handshake-এ asymmetric encryption দিয়ে নিরাপদে একটা symmetric key বিনিময় হয়, তারপর দ্রুত symmetric encryption চলে।
- ●Certificate ও CA chain প্রমাণ করে server সত্যিই যে দাবি করছে সে-ই।
সমস্যাটা কী?
তুমি যখন HTTP দিয়ে data পাঠাও, সেটা যায় plain text-এ — মাঝপথের যেকোনো router, ISP, বা পাবলিক Wi-Fi-তে বসে থাকা hacker সব পড়ে ফেলতে পারে। তোমার পাসওয়ার্ড, কার্ড নম্বর সব খোলা। শুধু পড়া নয়, কেউ data বদলেও দিতে পারে (man-in-the-middle attack)।
তিনটা জিনিস দরকার: (১) Confidentiality — কেউ যেন পড়তে না পারে, (২) Integrity — কেউ যেন বদলাতে না পারে, (৩) Authentication — তুমি যে server-এর সাথে কথা বলছ সে যেন আসলেই সঠিক server হয়, নকল কেউ না। এই তিনটাই দেয় TLS — আর HTTP-র সাথে TLS মিলেই হয় HTTPS।
মূল ধারণা
TLS (Transport Layer Security) হলো একটি protocol যা দুই পক্ষের মধ্যে data নিরাপদে (encrypted, যাচাইকৃত) আদান-প্রদান নিশ্চিত করে। SSL এর পুরোনো, এখন অপ্রচলিত নাম।
মূল চালাকি দুই ধরনের encryption-এর মিশ্রণে:
- Asymmetric encryption — দুটি key: public (সবার জন্য খোলা) আর private (গোপন)। একটা দিয়ে lock করলে অন্যটা দিয়ে unlock। নিরাপদ কিন্তু ধীর।
- Symmetric Encryption — একটাই shared key দিয়ে lock ও unlock। অনেক দ্রুত, কিন্তু সমস্যা হলো key-টা ও পাশকে নিরাপদে দেবে কীভাবে?
সমাধান: asymmetric দিয়ে নিরাপদে symmetric key বিনিময় করো, তারপর বাকি পুরো কথোপকথন দ্রুত symmetric-এ চালাও। এই key বিনিময় ও পরিচয় যাচাইয়ের পুরো প্রক্রিয়াটাই TLS handshake।
কীভাবে কাজ করে
Handshake-এর ধাপগুলো (সরলীকৃত, TLS 1.2)
| ধাপ | কে | কী করে |
|---|---|---|
| 1 | Client → Server | ClientHello: সমর্থিত TLS version, cipher list, random number |
| 2 | Server → Client | ServerHello: বেছে নেওয়া cipher + Certificate (public key সহ) |
| 3 | Client | Certificate যাচাই করে CA chain দিয়ে |
| 4 | Client → Server | server-এর public key দিয়ে encrypt করা গোপন তথ্য পাঠায় |
| 5 | দুই পক্ষ | একই session (symmetric) key বানায় |
| 6 | দুই পক্ষ | "Finished" বার্তা, এরপর সব data symmetric encryption-এ |
ধাপ ৪-এ client এমন কিছু পাঠায় যা শুধু server-এর private key দিয়েই খোলা যায় — তাই মাঝপথের কেউ ধরলেও বুঝতে পারবে না। এর থেকেই দুই পক্ষ একই session key পায়।
দ্রষ্টব্য: TLS 1.3-এ handshake আরও দ্রুত (১ round-trip), আর key বিনিময়ে শুধু (Ephemeral) Diffie-Hellman ব্যবহার হয়, যা forward secrecy দেয় — পুরোনো private key ফাঁস হলেও আগের session খোলা যায় না।
Certificate ও CA chain
Certificate হলো একটা digital document যাতে থাকে server-এর domain নাম, তার public key, আর একটি বিশ্বস্ত কর্তৃপক্ষের স্বাক্ষর।
কিন্তু certificate বিশ্বাস করব কেন? কারণ এটা স্বাক্ষর করেছে একটি Certificate Authority (CA) — যেমন Let's Encrypt, DigiCert। আর সেই CA-কে স্বাক্ষর করেছে আরেকটি root CA। এই শৃঙ্খল:
Root CA (browser-এ আগেই বিশ্বস্ত হিসেবে থাকা)
└─ signs → Intermediate CA
└─ signs → server-এর Certificate (example.com)
তোমার browser/OS-এ আগে থেকেই কিছু root CA-র তালিকা থাকে। Server-এর certificate ঐ chain ধরে কোনো বিশ্বস্ত root পর্যন্ত পৌঁছালে browser সবুজ তালা দেখায়; না পৌঁছালে "Not Secure" সতর্কতা।
ভাবো তুমি একটা তালাবদ্ধ বাক্স (public key) সবাইকে দিয়ে রাখলে, কিন্তু চাবি (private key) শুধু তোমার কাছে। যে কেউ বাক্সে গোপন চিঠি ভরে তালা মেরে তোমাকে পাঠাতে পারে, খুলতে পারবে শুধু তুমি — এটাই asymmetric। এখন certificate হলো জাতীয় পরিচয়পত্রের মতো, যেটার ওপর সরকার (CA) সিল মেরেছে। দোকানদার তোমার পরিচয়পত্র দেখে নিশ্চিত হয় তুমি আসল — কারণ সরকারের সিল সে বিশ্বাস করে। নকল কেউ সিল বসাতে পারবে না।
কৌশল
কী encrypt হয়, কী হয় না:
| অংশ | encrypted? |
|---|---|
| HTTP body, headers, cookie, URL path | হ্যাঁ (handshake-এর পর) |
| গন্তব্য IP address | না (routing-এর জন্য দরকার) |
| Domain নাম (SNI/DNS) | সাধারণত না (Encrypted SNI ছাড়া) |
মানে কেউ দেখতে পায় তুমি কোন server-এ যাচ্ছ, কিন্তু কী data আদান-প্রদান করছ তা পারে না।
কখন ব্যবহার করবে / করবে না
- সবসময় HTTPS ব্যবহার করো — login, payment তো বটেই, সাধারণ blog-এও। আধুনিক browser HTTP-কে "Not Secure" দেখায়, SEO-তেও জরিমানা।
- TLS 1.3 বেছে নাও যেখানে সম্ভব — দ্রুত ও নিরাপদ। পুরোনো SSL 3.0 / TLS 1.0/1.1 বন্ধ করে দাও।
Self-signed certificate (নিজে নিজে বানানো, কোনো CA-র স্বাক্ষর ছাড়া) production-এ ব্যবহার করো না — browser বিশ্বাস করবে না, ব্যবহারকারী ভীতিকর সতর্কতা দেখবে। আর certificate-এর মেয়াদ (expiry) খেয়াল রাখো; expired certificate পুরো site ডাউন করে দিতে পারে। auto-renewal সেট করে রাখা বুদ্ধিমানের কাজ।
বাস্তব উদাহরণ
তুমি bKash-এর মতো একটা payment app বানাচ্ছ:
- ব্যবহারকারী
https://pay.example.com-এ ঢোকে। TLS handshake শুরু। - Server তার certificate পাঠায়, যা Let's Encrypt স্বাক্ষরিত। Browser CA chain যাচাই করে — ঠিক আছে।
- Asymmetric দিয়ে নিরাপদে একটা session key তৈরি হয়।
- এরপর কার্ড নম্বর, OTP — সব symmetric encryption-এ যায়, দ্রুত ও নিরাপদ।
- পাবলিক Wi-Fi-তে বসা কেউ data ধরলেও শুধু এলোমেলো byte দেখবে, কিছু পড়তে পারবে না।
Interview-এ "TLS-এ symmetric আর asymmetric দুটোই কেন?" — সবচেয়ে ভালো উত্তর: asymmetric নিরাপদ কিন্তু ধীর, তাই শুধু handshake-এ session key বিনিময়ে ব্যবহার হয়; এরপর পুরো data দ্রুত symmetric-এ চলে। এটাকে বলে "hybrid encryption"। আর forward secrecy উল্লেখ করলে বাড়তি নম্বর।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. TLS handshake-এ asymmetric encryption কেন ব্যবহার হয়?
2. Certificate কী প্রমাণ করে?
3. Handshake শেষে আসল application data কোন encryption-এ যায়?