TLS আর HTTPS — handshake, certificate আর বিশ্বাসের শিকল

১ · TLS কী দেয় আর কী দেয় না — খামের ভেতরের চিঠি

IP, TCP, DNS, HTTP — এদের মূল নকশায় ডেটা যায় খোলা অবস্থায়; পথের router, একই Wi-Fi-র যে কেউ বা ISP পড়তে, এমনকি বদলাতেও পারে। পর্ব ৪৬-এ নিরাপত্তার তিন লক্ষ্য দেখেছেন: গোপনীয়তা, অখণ্ডতা আর প্রাপ্যতা (CIA). পর্ব ৪৭-এ দেখেছেন সেগুলোর গাণিতিক হাতিয়ার: symmetric এনক্রিপশন, hash, digital signature আর Diffie-Hellman. TLS (Transport Layer Security) হলো সেই হাতিয়ারগুলো জোড়া দিয়ে বানানো একটি protocol, যা TCP-র ওপরে বসে যেকোনো অ্যাপের বাইটকে সুরক্ষিত পাইপে পরিণত করে। আর HTTPS মানে শুধু “HTTP, কিন্তু TLS-এর ভেতর দিয়ে” — সাধারণত TCP port 443-এ (পর্ব ৩৬)।

TLS যা দেয়

TLS যা দেয় না

২ · SSL থেকে TLS 1.3 — ইতিহাস আর ভাঙনের শিক্ষা

১৯৯০-এর দশকের মাঝামাঝি Netscape ওয়েবে কেনাকাটা সম্ভব করতে SSL (Secure Sockets Layer) বানায়। SSL 1.0 প্রকাশই হয়নি, SSL 2.0-তে গুরুতর ত্রুটি ছিল, SSL 3.0 (১৯৯৬) টিকেছিল বহু বছর। এরপর IETF মানটি হাতে নিয়ে নাম দেয় TLS. আজও মানুষ “SSL certificate” বলে — কিন্তু SSL-এর সব সংস্করণ বহু আগেই নিষিদ্ধ।

প্রধান ব্রাউজারগুলো ২০২০ সালের আশপাশে TLS 1.0 আর 1.1 সমর্থন তুলে নেয়; RFC 8996 (মার্চ ২০২১) সেটিকে আনুষ্ঠানিক রূপ দেয়। তাই খুব পুরোনো যন্ত্র আধুনিক সাইটে সংযোগই করতে পারে না।

বিখ্যাত ভাঙনগুলো — প্রতিটি একটি শিক্ষা

নিচের আক্রমণগুলো শুধু ধারণা হিসেবে, যাতে বোঝেন TLS 1.3 কেন এমন। প্রতিটির বিস্তারিত গবেষণাপত্রে আছে; সময় আর প্রভাব মোটামুটি হিসেবে দেওয়া।

৩ · TLS 1.3 handshake — বার্তা ধরে ধরে

TCP সংযোগ হয়ে গেছে (পর্ব ২৯)। এখন ব্রাউজার www.example.com-এর সাথে TLS শুরু করবে। পুরো কাজের লক্ষ্য দুটি: (১) দুই পক্ষের হাতে এমন একটি গোপন সংখ্যা আসা যা পথের কেউ জানে না, আর (২) ক্লায়েন্টের নিশ্চিত হওয়া যে অপর প্রান্তে সত্যিই www.example.com. প্রথমটি আসে ephemeral Diffie-Hellman (সাধারণত X25519 curve-এ, তাই নাম ECDHE) থেকে, দ্বিতীয়টি certificate আর স্বাক্ষর থেকে। গণিত পর্ব ৪৭-এ (cryptography-basics.html); এখানে দেখব বার্তাগুলো কীভাবে সাজানো।

ClientHello — প্রথম বার্তায় কী কী থাকে

• supported_versions: “আমি TLS 1.3 (0x0304) পারি”. পুরোনো legacy_version ঘরে ইচ্ছা করেই TLS 1.2-এর মান 0x0303 লেখা থাকে — কারণ নিচে।
• cipher_suites: কোন AEAD আর hash পছন্দ, যেমন TLS_AES_128_GCM_SHA256.
• key_share: ক্লায়েন্টের অস্থায়ী DH public key — আগে থেকেই, অনুমান করে যে সার্ভার X25519 নেবে। এখানেই এক RTT বাঁচে।
• supported_groups, signature_algorithms: কোন curve আর কোন স্বাক্ষর-পদ্ধতি চলবে।
• server_name (SNI): “আমি www.example.com চাই” — খোলা অবস্থায়।
• ALPN: “h2 বা http/1.1” (ALPN, পর্ব ৩৭)।
• random: ৩২ বাইটের এলোমেলো সংখ্যা, যাতে প্রতিটি handshake আলাদা হয়।

ServerHello-তে সার্ভার একটি cipher suite বেছে নেয় আর নিজের key_share পাঠায়। এই মুহূর্তে দুই পক্ষ একই ECDHE গোপন সংখ্যা হিসাব করতে পারে — আর তা থেকে handshake-এর চাবি। তাই ServerHello-র পরের সব কিছু এনক্রিপ্টেড, certificate-ও। TLS 1.2-এ certificate যেত খোলা অবস্থায়।

নিজের যন্ত্রে একটি আসল handshake

Runner-এ openssl আছে কি না আগে দেখা হয়; থাকলে একটি অস্থায়ী self-signed certificate বানিয়ে 127.0.0.1-এ s_server চালানো হয়, আর s_client তার সাথে সংযোগ করে। -msg প্রতিটি record-এর header আর ভেতরের বার্তা দেখায়; নিচের awk সেটাকে সাজিয়ে দেখায় তারের ওপর কোন record type গেল আর ভেতরে আসলে কী ছিল। কোনো বাইরের সার্ভারে যাওয়া হয় না।

# A real TLS 1.3 handshake on loopback (127.0.0.1): openssl s_server <-> s_client.
command -v openssl >/dev/null || { echo "openssl নেই"; exit 0; }
cd "$(mktemp -d)" || exit 1
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -keyout k.pem \
  -out c.pem -days 1 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost" 2>/dev/null
openssl s_server -accept 127.0.0.1:8443 -cert c.pem -key k.pem -alpn h2,http/1.1 \
  -naccept 1 -quiet >srv.log 2>&1 &
sleep 1
echo hi | timeout 10 openssl s_client -connect 127.0.0.1:8443 -servername localhost \
  -alpn h2 -CAfile c.pem -verify_hostname localhost -msg >cli.log 2>&1
echo "== records on the wire (>>> client sends, <<< client receives) =="
awk 'BEGIN { n["16"]="handshake (plaintext)"; n["17"]="application_data (ENCRYPTED)"
             n["14"]="change_cipher_spec (compatibility only)"; n["15"]="alert" }
  /RecordHeader/ { d = $1; getline; print d, "record type", $1, n[$1]; next }
  /InnerContent/ { getline; if ($1 == "17") print "        inside: application data (hi)"; next }
  /^(<<<|>>>) TLS 1.3, (Handshake|Alert)/ { sub(/.*\], /, ""); print "        inside: " $0 }
' cli.log
echo "== summary =="
grep -E '^(New, |ALPN|Server Temp Key|Peer signature type|Verification:)' cli.log
wait

== records on the wire (>>> client sends, <<< client receives) ==
>>> record type 16 handshake (plaintext)
        inside: ClientHello
<<< record type 16 handshake (plaintext)
        inside: ServerHello
<<< record type 14 change_cipher_spec (compatibility only)
<<< record type 17 application_data (ENCRYPTED)
        inside: EncryptedExtensions
<<< record type 17 application_data (ENCRYPTED)
        inside: Certificate
<<< record type 17 application_data (ENCRYPTED)
        inside: CertificateVerify
<<< record type 17 application_data (ENCRYPTED)
        inside: Finished
>>> record type 14 change_cipher_spec (compatibility only)
>>> record type 17 application_data (ENCRYPTED)
        inside: Finished
>>> record type 17 application_data (ENCRYPTED)
        inside: application data (hi)
>>> record type 17 application_data (ENCRYPTED)
        inside: warning close_notify
== summary ==
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
ALPN protocol: h2

ClientHello-র বাইট পড়া

এবার উল্টো দিক থেকে: হাতে বানানো একটি ছোট ClientHello-র hex থেকে প্রতিটি ঘর পড়া — Wireshark যা করে, তার একটি ক্ষুদ্র রূপ। Random আর key-এর বাইট এখানে বানানো (আসলে এলোমেলো হয়)। শেষে একটি decoder cipher suite-এর লম্বা নাম ভেঙে দেখায়।

// A hand-built minimal TLS 1.3 ClientHello for www.example.com (random and key are fillers).
const hex = ["16 0301 00a0", "01 00009c", "0303", "11".repeat(32), "00", "0006 1301 1302 1303",
  "01 00", "006d", "0000 0014 0012 00 000f 7777772e6578616d706c652e636f6d",
  "000a 0004 0002 001d", "000d 0006 0004 0403 0804", "0010 000e 000c 02 6832 08 687474702f312e31",
  "002b 0003 02 0304", "0033 0026 0024 001d 0020" + "ab".repeat(32)].join("").replace(/ /g, "");
const b = hex.match(/../g).map(h => parseInt(h, 16)); let i = 0;
const u = (n) => { let v = 0; for (let k = 0; k < n; k++) v = v * 256 + b[i++]; return v; };
const x = (v) => "0x" + v.toString(16).padStart(4, "0");
const u16s = (d) => d.filter((_, k) => k % 2 === 0).map((hi, k) => x(hi * 256 + d[2 * k + 1])).join(" ");
const SUITE = { 0x1301: "TLS_AES_128_GCM_SHA256", 0x1302: "TLS_AES_256_GCM_SHA384", 0x1303: "TLS_CHACHA20_POLY1305_SHA256" };
const EXT = { 0: "server_name", 10: "supported_groups", 13: "signature_algorithms", 16: "alpn", 43: "supported_versions", 51: "key_share" };
console.log(`total ${b.length} bytes`);
console.log(`record   : type ${u(1)} (22 = handshake), version ${x(u(2))}, length ${u(2)}`);
console.log(`handshake: type ${u(1)} (1 = ClientHello), length ${u(3)}`);
console.log(`legacy_version ${x(u(2))}, random ${hex.substr(2 * i, 8)}... (32 bytes)`); i += 32;
const sid = u(1); i += sid; console.log(`legacy_session_id: ${sid} bytes`);
for (let end = u(2) + i; i < end; ) { const s = u(2); console.log(`  cipher suite ${x(s)} ${SUITE[s]}`); }
i += 1 + b[i]; console.log("compression: null only");
for (let end = u(2) + i; i < end; ) {
  const t = u(2), len = u(2), d = b.slice(i, i + len); i += len;
  const info = t === 0 ? "host = " + String.fromCharCode(...d.slice(5))
    : t === 43 ? u16s(d.slice(1)) + " (= TLS 1.3)"
    : t === 51 ? `group ${x(d[2] * 256 + d[3])} (x25519), public key ${d[4] * 256 + d[5]} bytes`
    : t === 16 ? String.fromCharCode(...d.slice(2)).replace(/[\x00-\x1f]/g, " ").trim() : u16s(d.slice(2));
  console.log(`  ext ${x(t)} ${EXT[t].padEnd(20)} ${String(len).padStart(2)} B: ${info}`);
}
console.log(i === b.length ? "parsed every byte" : `left over: ${b.length - i}`);
function decode(name) {                      // read a cipher-suite name piece by piece
  const [, kxAuth, cipher, hash] = name.match(/^TLS_(?:(\w+?)_WITH_)?(\w+)_(SHA\d*)$/);
  if (!kxAuth) return `${name}\n    TLS 1.3: AEAD ${cipher}, hash ${hash} (for HKDF); key exchange + signature chosen separately`;
  const [kx, auth = kx] = kxAuth.split("_");
  return `${name}\n    TLS 1.2: key exchange ${kx}${kx.startsWith("ECDHE") || kx.startsWith("DHE") ? " (forward secrecy)" : " (NO forward secrecy)"}, ` +
         `auth ${auth}, cipher ${cipher}, hash ${hash}`;
}
["TLS_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA"].forEach(n => console.log(decode(n)));

total 165 bytes
record   : type 22 (22 = handshake), version 0x0301, length 160
handshake: type 1 (1 = ClientHello), length 156
legacy_version 0x0303, random 11111111... (32 bytes)
legacy_session_id: 0 bytes
  cipher suite 0x1301 TLS_AES_128_GCM_SHA256
  cipher suite 0x1302 TLS_AES_256_GCM_SHA384
  cipher suite 0x1303 TLS_CHACHA20_POLY1305_SHA256
compression: null only
  ext 0x0000 server_name          20 B: host = www.example.com
  ext 0x000a supported_groups      4 B: 0x001d
  ext 0x000d signature_algorithms  6 B: 0x0403 0x0804
  ext 0x0010 alpn                 14 B: h2 http/1.1
  ext 0x002b supported_versions    3 B: 0x0304 (= TLS 1.3)
  ext 0x0033 key_share            38 B: group 0x001d (x25519), public key 32 bytes
parsed every byte
TLS_AES_128_GCM_SHA256
    TLS 1.3: AEAD AES_128_GCM, hash SHA256 (for HKDF); key exchange + signature chosen separately
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS 1.2: key exchange ECDHE (forward secrecy), auth RSA, cipher AES_128_GCM, hash SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
    TLS 1.2: key exchange RSA (NO forward secrecy), auth RSA, cipher AES_128_CBC, hash SHA

Key schedule — একটি গোপন সংখ্যা থেকে অনেক চাবি

ECDHE থেকে পাওয়া একটি গোপন সংখ্যা দিয়েই সব কাজ চালানো বিপজ্জনক: এক জায়গার দুর্বলতা সবখানে ছড়াবে। তাই TLS 1.3 HKDF (HMAC-ভিত্তিক key derivation, RFC 5869) দিয়ে একটি key schedule চালায়, মোটামুটি তিন ধাপে:

1. Early secret — resumption-এর PSK থাকলে তা থেকে (0-RTT-এর চাবি এখান থেকে), না থাকলে শূন্য থেকে।
2. Handshake secret — ECDHE-র গোপন সংখ্যা মিশিয়ে। এখান থেকে দুই দিকের আলাদা handshake traffic key, ClientHello…ServerHello-র hash-এর সাথে বাঁধা।
3. Master secret — এখান থেকে দুই দিকের application traffic key (সার্ভারের Finished পর্যন্ত transcript-এ বাঁধা), আর resumption-এর গোপন সংখ্যা।

প্রতিটি চাবি নির্দিষ্ট লেবেল (“c hs traffic”, “s ap traffic” ইত্যাদি) আর transcript hash দিয়ে আলাদা; দুই দিকের চাবি কখনো এক নয়, আর দীর্ঘ সংযোগে KeyUpdate দিয়ে application key নতুন করা যায়। আর যেহেতু DH key প্রতি সংযোগে নতুন আর কাজ শেষে মুছে ফেলা হয়, সার্ভারের certificate key পরে চুরি হলেও আগের রেকর্ড করা আলাপ খোলা যায় না — এটাই forward secrecy.

৪ · RTT, resumption, cipher suite আর record layer

TLS 1.2-এ কেন ২ RTT লাগত

TLS 1.2-এর পূর্ণ handshake: ক্লায়েন্ট ClientHello পাঠায় (কোনো key share ছাড়া) → সার্ভার ServerHello, Certificate, ServerKeyExchange, ServerHelloDone পাঠায় → ক্লায়েন্ট ClientKeyExchange, ChangeCipherSpec, Finished পাঠায় → সার্ভার ChangeCipherSpec, Finished পাঠায়। ক্লায়েন্ট key share পাঠাতে পারে সার্ভারের পছন্দ জানার পরে, তাই এক RTT বেশি। TLS 1.3 অনুমান করে প্রথমেই key share দেয়; অনুমান ভুল হলে সার্ভার HelloRetryRequest পাঠায় আর এক RTT বাড়ে — বাস্তবে বিরল। পর্ব ৩৩-এর ক্যালকুলেটর অনুযায়ী নতুন সংযোগে প্রথম বাইট পর্যন্ত: TCP + TLS 1.2 = ৪ RTT, TCP + TLS 1.3 = ৩ RTT.

Resumption আর 0-RTT

NewSessionTicket-এ পাওয়া ticket পরের বার ClientHello-তে pre_shared_key extension হিসেবে যায় — একে বলে session resumption. দুটি ধরন আছে: শুধু PSK (দ্রুত, কিন্তু forward secrecy নেই), আর PSK + নতুন ECDHE (psk_dhe_ke, ব্রাউজারে সাধারণ)। Resumption-এ certificate আর স্বাক্ষর লাগে না, তাই CPU আর বাইট বাঁচে। এর ওপর ক্লায়েন্ট চাইলে প্রথম বার্তার সাথেই early data (0-RTT) পাঠাতে পারে — কিন্তু সেই ডেটা replay হতে পারে, তাই শুধু idempotent অনুরোধে। ঝুঁকি আর প্রতিরক্ষা (425 Too Early ইত্যাদি) পর্ব ৩৩-এ বিস্তারিত; এখানে আবার নয়।

Cipher suite — নাম পড়তে শেখা

TLS 1.2-এর নামে চারটি সিদ্ধান্ত একসাথে লেখা থাকত। TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ভাঙলে:

TLS 1.3 নাম ছোট করেছে: TLS_AES_128_GCM_SHA256 শুধু AEAD আর HKDF-এর hash বলে; key exchange আর স্বাক্ষর আলাদা extension-এ (supported_groups, signature_algorithms) ঠিক হয়। RFC 8446-এ মোট পাঁচটি suite: 0x1301 TLS_AES_128_GCM_SHA256 (সব বাস্তবায়নে বাধ্যতামূলক), 0x1302 TLS_AES_256_GCM_SHA384, 0x1303 TLS_CHACHA20_POLY1305_SHA256 (AES-এর hardware সহায়তা নেই এমন ফোনে দ্রুত), আর কম ব্যবহৃত দুটি CCM suite (0x1304, 0x1305). অংশ ৩-এর decoder-এর শেষ লাইনটি দেখুন: TLS_RSA_WITH_AES_128_CBC_SHA-এ key exchange-ই RSA — সার্ভারের দীর্ঘমেয়াদি key দিয়ে গোপন সংখ্যা পাঠানো, তাই forward secrecy নেই, আর “SHA” মানে SHA-1-ভিত্তিক HMAC; TLS 1.3 এর কোনোটিই রাখেনি।

Record layer — খামের মাপ

Handshake-এর পর সব ডেটা যায় record-এ। প্রতিটি record-এর ৫ বাইটের header: content type (২০ change_cipher_spec, ২১ alert, ২২ handshake, ২৩ application_data), পুরোনো version (0x0303) আর দৈর্ঘ্য। একটি record-এ সর্বোচ্চ ২^১৪ = ১৬,৩৮৪ বাইট মূল ডেটা। TLS 1.3-এ এনক্রিপ্ট করা record-এর ভেতরে থাকে ডেটা + আসল content type (১ বাইট) + ঐচ্ছিক শূন্য-padding, আর শেষে AEAD-এর ১৬ বাইটের যাচাই-ট্যাগ। প্রতিটি record-এর nonce আসে একটি ৬৪-bit record নম্বর আর একটি স্থির IV-এর XOR থেকে — নম্বর কোথাও পাঠানো হয় না, দুই পক্ষ গুনে রাখে; তাই record বাদ দেওয়া বা ক্রম বদলালে যাচাই ব্যর্থ হয়।

৫ · Certificate আর X.509 — ডিজিটাল পরিচয়পত্র

সার্ভারের public key তো যে কেউ বানাতে পারে। ক্লায়েন্ট কীভাবে জানবে “এই key-টিই www.example.com-এর”? উত্তর: একটি বিশ্বস্ত তৃতীয় পক্ষ — CA — সেই দাবিতে স্বাক্ষর করে। স্বাক্ষর করা এই দলিলের মান-আকার X.509 (সংস্করণ ৩; ইন্টারনেটের নিয়ম RFC 5280-এ)। প্রধান ঘরগুলো:

নিজে একটি ছোট PKI বানানো

নিচের script একটি অস্থায়ী “Lab Root CA” বানায় (self-signed, CA:TRUE), তারপর localhost-এর জন্য একটি key আর CSR (certificate চাওয়ার আবেদন) বানিয়ে CA দিয়ে স্বাক্ষর করায় — SAN-সহ। শেষে চারভাবে যাচাই। পুরো কাজ একটি অস্থায়ী ফোল্ডারে, কোনো বাইরের সংযোগ নেই; -subj দেওয়ায় কোনো প্রশ্নও করে না।

# A throwaway lab CA and a "localhost" certificate - nothing here touches the internet.
command -v openssl >/dev/null || { echo "openssl নেই - এই runner-এ চালানো যাবে না"; exit 0; }
openssl version
cd "$(mktemp -d)" || exit 1
newca() {  # $1 = file prefix, $2 = CA name: self-signed, CA:TRUE, may sign certificates
  openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
    -keyout "$1.key" -out "$1.crt" -days 30 -subj "/CN=$2" \
    -addext "basicConstraints=critical,CA:TRUE" \
    -addext "keyUsage=critical,keyCertSign,cRLSign" 2>/dev/null
}
newca labca "Lab Root CA"
newca otherca "Some Other CA"

# leaf key + certificate signing request, then the lab CA signs it (with SAN)
openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout leaf.key -out leaf.csr -subj "/CN=localhost" 2>/dev/null
printf '%s\n' "subjectAltName=DNS:localhost,IP:127.0.0.1" "basicConstraints=CA:FALSE" \
  "extendedKeyUsage=serverAuth" > leaf.ext
openssl x509 -req -in leaf.csr -CA labca.crt -CAkey labca.key -CAcreateserial \
  -days 7 -extfile leaf.ext -out leaf.crt 2>/dev/null

echo "== leaf certificate =="
openssl x509 -in leaf.crt -noout -subject -issuer -dates -ext subjectAltName,basicConstraints
echo "== checks =="
chk() { echo "--- $1"; shift; openssl verify "$@" leaf.crt 2>&1 | head -2; }
chk "trusted lab CA"                  -CAfile labca.crt
chk "lab CA + name localhost"         -CAfile labca.crt -verify_hostname localhost
chk "lab CA + name www.example.com"   -CAfile labca.crt -verify_hostname www.example.com
chk "only the OTHER CA is trusted"    -CAfile otherca.crt
echo "done"

OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
== leaf certificate ==
subject=CN = localhost
issuer=CN = Lab Root CA
notBefore=Oct 26 17:44:14 2026 GMT
notAfter=Nov  2 17:44:14 2026 GMT
X509v3 Subject Alternative Name: 
    DNS:localhost, IP Address:127.0.0.1
X509v3 Basic Constraints: 
    CA:FALSE
== checks ==
--- trusted lab CA
leaf.crt: OK
--- lab CA + name localhost
leaf.crt: OK
--- lab CA + name www.example.com
CN = localhost
error 62 at 0 depth lookup: hostname mismatch
--- only the OTHER CA is trusted
CN = localhost
error 20 at 0 depth lookup: unable to get local issuer certificate
done

৬ · বিশ্বাসের শিকল — chain, path validation আর hostname

ব্রাউজার বা OS সাথে নিয়ে আসে কয়েকশো root certificate-এর একটি তালিকা — trust store. Windows, macOS, Android-এর নিজস্ব তালিকা আছে; Firefox রাখে নিজের (Mozilla-র) তালিকা; Linux-এ সাধারণত ca-certificates প্যাকেজ। সার্ভারের leaf certificate-এ সরাসরি root স্বাক্ষর করে না; মাঝখানে থাকে এক বা একাধিক intermediate certificate. পুরো সারিটিই certificate chain: leaf → intermediate → root.

Intermediate কেন?

• Root-এর key অফলাইনে: root key থাকে নিরাপদ hardware-এ (HSM), প্রায় সবসময় বন্ধ; প্রতিদিনের স্বাক্ষর করে intermediate.
• ক্ষতি সীমিত: intermediate-এর key ফাঁস হলে শুধু সেটি বাতিল; root বদলাতে কোটি যন্ত্রের trust store হালনাগাদ লাগত — বছরের কাজ।
• নমনীয়তা: ভিন্ন কাজে ভিন্ন intermediate; নতুন root-কে পুরোনো root দিয়ে cross-sign করে পুরোনো যন্ত্রেও চালানো।

নিয়ম: সার্ভার leaf আর সব intermediate পাঠাবে, root নয়। Intermediate পাঠাতে ভুলে গেলে অনেক ব্রাউজার আগের ভিজিটের cache থেকে বা certificate-এ লেখা ঠিকানা থেকে নামিয়ে নিয়ে কাজ চালায় — কিন্তু curl, মোবাইল অ্যাপ আর অন্য সার্ভার ব্যর্থ হয়। “ব্রাউজারে চলে, API-তে চলে না” — এর সবচেয়ে সাধারণ কারণ এটি।

Hostname আর wildcard-এর নিয়ম

• নাম মেলানো ছোট-বড় হাতের অক্ষর না দেখে; শুধু SAN থেকে।
• *.example.com মেলে api.example.com-এর সাথে — ঠিক একটি বাম-দিকের label.
• মেলে না a.b.example.com (দুই label) বা খোদ example.com (শূন্য label) — তাই অনেক certificate-এ দুটিই রাখা হয়: example.com আর *.example.com.
• Wildcard শুধু সবচেয়ে বামের পুরো label-এ; CA-রা *.com-এর মতো পুরো public suffix-এর wildcard দেয় না।
• IP ঠিকানায় সংযোগ করলে SAN-এ “IP Address” ধরনের এন্ট্রি লাগে (ওপরের lab certificate-এ যেমন 127.0.0.1).

এবার এই সব যাচাই একটি simulator-এ, ডেটার রেকর্ড দিয়ে। আসল স্বাক্ষর-গণিতের বদলে key ID মেলানো হয়েছে; বাকি ক্রম ব্রাউজারের মতোই। আটটি শিকল — একটি ঠিক, বাকিগুলো একেকভাবে ভাঙা।

// Toy certificate-path validator on plain data records (a matching key ID stands in for the signature check).
const TRUST_STORE = [{ subject: "Demo Root R1", ski: "R1" }], NOW = new Date("2026-10-26T12:00:00Z");
const leaf  = (o) => ({ subject: "www.example.com", issuer: "Demo CA 1", aki: "I1", ca: false,
  san: ["www.example.com", "example.com"], from: "2026-09-01", to: "2026-11-29", ...o });
const inter = (o) => ({ subject: "Demo CA 1", issuer: "Demo Root R1", ski: "I1", aki: "R1",
  ca: true, from: "2024-01-01", to: "2029-01-01", ...o });
const nameMatches = (host, pat, dot = host.indexOf(".")) =>   // "*." covers exactly ONE leftmost label
  pat.startsWith("*.") ? dot > 0 && host.slice(dot + 1) === pat.slice(2) : host === pat;
function validate(host, chain) {
  const say = (good, msg) => { console.log((good ? "   ok   " : "   FAIL ") + msg); return good; }, [lf, ...sent] = chain;
  if (!say(lf.san.some(p => nameMatches(host, p)), `${host} matches SAN [${lf.san.join(", ")}]`)) return;
  for (let cur = lf, isLeaf = true; ; isLeaf = false) {
    if (!say(new Date(cur.from) <= NOW && NOW <= new Date(cur.to + "T23:59:59Z"), `"${cur.subject}" valid ${cur.from} .. ${cur.to}`)) return;
    if (!isLeaf && !say(cur.ca, `"${cur.subject}" is a CA (basicConstraints CA:TRUE)`)) return;
    if (TRUST_STORE.some(r => r.subject === cur.issuer && r.ski === cur.aki))
      return say(true, `issuer "${cur.issuer}" is in the trust store  => TRUSTED`);
    const up = sent.find(c => c.subject === cur.issuer && c.ski === cur.aki);
    if (!say(up && up.subject !== up.issuer, `issuer "${cur.issuer}" ` +
        (!up ? "not sent by server and not in trust store" : up.subject === up.issuer ?
         "is a self-signed root that is NOT in the trust store" : "found in the chain the server sent"))) return;
    cur = up;
  }
}
const selfRoot = { subject: "Home Lab CA", issuer: "Home Lab CA", ski: "H1", aki: "H1", ca: true, from: "2026-01-01", to: "2036-01-01" };
const cases = [["good chain", "www.example.com", [leaf(), inter()]],
  ["expired leaf", "www.example.com", [leaf({ to: "2026-10-20" }), inter()]],
  ["wrong name", "shop.example.com", [leaf(), inter()]],
  ["wildcard, one label", "api.example.com", [leaf({ san: ["*.example.com"] }), inter()]],
  ["wildcard, two labels", "a.b.example.com", [leaf({ san: ["*.example.com"] }), inter()]],
  ["missing intermediate", "www.example.com", [leaf()]],
  ["untrusted root", "www.example.com", [leaf({ issuer: "Home Lab CA", aki: "H1" }), selfRoot]],
  ["non-CA as intermediate", "www.example.com", [leaf(), inter({ ca: false })]]];
for (const [label, host, chain] of cases) { console.log(`## ${label}`); validate(host, chain); }

## good chain
   ok   www.example.com matches SAN [www.example.com, example.com]
   ok   "www.example.com" valid 2026-09-01 .. 2026-11-29
   ok   issuer "Demo CA 1" found in the chain the server sent
   ok   "Demo CA 1" valid 2024-01-01 .. 2029-01-01
   ok   "Demo CA 1" is a CA (basicConstraints CA:TRUE)
   ok   issuer "Demo Root R1" is in the trust store  => TRUSTED
## expired leaf
   ok   www.example.com matches SAN [www.example.com, example.com]
   FAIL "www.example.com" valid 2026-09-01 .. 2026-10-20
## wrong name
   FAIL shop.example.com matches SAN [www.example.com, example.com]
## wildcard, one label
   ok   api.example.com matches SAN [*.example.com]
   ok   "www.example.com" valid 2026-09-01 .. 2026-11-29
   ok   issuer "Demo CA 1" found in the chain the server sent
   ok   "Demo CA 1" valid 2024-01-01 .. 2029-01-01
   ok   "Demo CA 1" is a CA (basicConstraints CA:TRUE)
   ok   issuer "Demo Root R1" is in the trust store  => TRUSTED
## wildcard, two labels
   FAIL a.b.example.com matches SAN [*.example.com]
## missing intermediate
   ok   www.example.com matches SAN [www.example.com, example.com]
   ok   "www.example.com" valid 2026-09-01 .. 2026-11-29
   FAIL issuer "Demo CA 1" not sent by server and not in trust store
## untrusted root
   ok   www.example.com matches SAN [www.example.com, example.com]
   ok   "www.example.com" valid 2026-09-01 .. 2026-11-29
   FAIL issuer "Home Lab CA" is a self-signed root that is NOT in the trust store
## non-CA as intermediate
   ok   www.example.com matches SAN [www.example.com, example.com]
   ok   "www.example.com" valid 2026-09-01 .. 2026-11-29
   ok   issuer "Demo CA 1" found in the chain the server sent
   ok   "Demo CA 1" valid 2024-01-01 .. 2029-01-01
   FAIL "Demo CA 1" is a CA (basicConstraints CA:TRUE)

ত্রুটির বার্তা দেখে কারণ খোঁজা

সমস্যা খোঁজার চেকলিস্ট (নিজের সার্ভারে)

1. যন্ত্রের তারিখ-সময় ঠিক আছে কি না — date -u; ঘড়ি মেলানো চালু কি না।
2. নাম: openssl x509 -noout -ext subjectAltName দিয়ে SAN দেখা; যে নামে সংযোগ, তা আছে কি না।
3. শিকল: openssl s_client -connect <নিজের-সার্ভার>:443 -servername <নাম> -showcerts — সার্ভার intermediate পাঠাচ্ছে কি না, “Verify return code” কী।
4. মেয়াদ: openssl x509 -noout -enddate; স্বয়ংক্রিয় নবায়ন (ACME) চলছে কি না।
5. ঠিক certificate: একাধিক সাইটের সার্ভারে SNI অনুযায়ী ঠিক ফাইল, load balancer আর origin দুই জায়গাতেই হালনাগাদ।
6. অন্য যন্ত্র থেকে, অন্য নেটওয়ার্ক থেকে পরীক্ষা — শুধু এক নেটওয়ার্কে সমস্যা হলে মাঝের proxy বা interception সন্দেহ করুন।

৭ · Web PKI — CA, revocation, Certificate Transparency আর ACME

ওয়েবের পুরো বিশ্বাস-ব্যবস্থাকে বলে Web PKI: CA-গুলো, ব্রাউজার আর OS-নির্মাতাদের root program (কোন CA trust store-এ থাকবে), আর CA/Browser Forum-এর Baseline Requirements (CA কীভাবে যাচাই করবে)। এর সবচেয়ে বড় দুর্বলতা: trust store-এর যেকোনো CA যেকোনো domain-এর certificate দিতে পারে। একটি CA ভুল করলে বা আক্রান্ত হলে সবাই ঝুঁকিতে। ২০১১ সালে ডাচ CA DigiNotar আক্রান্ত হয়ে google.com-সহ বহু নামের নকল certificate তৈরি হয়েছিল বলে প্রকাশিত হয়; ব্রাউজারগুলো সেটিকে trust store থেকে সরিয়ে দেয় আর প্রতিষ্ঠানটি দেউলিয়া হয়। এমন ঘটনার উত্তরেই নিচের ব্যবস্থাগুলো।

DV, OV, EV — যাচাইয়ের তিন স্তর

DV (Domain Validated): CA শুধু যাচাই করে আবেদনকারী domain-টি নিয়ন্ত্রণ করেন — একটি ফাইল বা DNS record বসিয়ে। OV (Organization Validated): প্রতিষ্ঠানের অস্তিত্বও যাচাই। EV (Extended Validation): আরও কঠোর কাগজপত্র যাচাই। একসময় EV সাইটে ব্রাউজার সবুজ বারে প্রতিষ্ঠানের নাম দেখাত; ব্যবহারকারীরা পার্থক্য খেয়াল করেন না দেখে প্রধান ব্রাউজারগুলো ২০১৯ সালের আশপাশে তা সরিয়ে দেয়। এনক্রিপশনের শক্তি তিনটিতেই এক।

Revocation — বাতিল খবর পৌঁছানো

• CRL: CA বাতিল certificate-এর serial নম্বরের স্বাক্ষরিত তালিকা প্রকাশ করে। তালিকা বড় হতে পারে, আর নিয়মিত নামাতে হয়।
• OCSP: ক্লায়েন্ট CA-কে জিজ্ঞেস করে “এই একটি certificate বৈধ?” — কিন্তু এতে CA জেনে যায় আপনি কোন সাইটে যাচ্ছেন, প্রতিটি সংযোগে দেরি বাড়ে, আর OCSP সার্ভার উত্তর না দিলে বেশিরভাগ ব্রাউজার “চলুক” ধরে নেয় (soft-fail) — অর্থাৎ যে আক্রমণকারী পথ নিয়ন্ত্রণ করে, সে উত্তর আটকে দিলেই হলো।
• OCSP stapling: সার্ভার নিজেই CA-র স্বাক্ষরিত সাম্প্রতিক OCSP উত্তর handshake-এ জুড়ে দেয় — গোপনীয়তা আর দেরি দুই সমস্যাই কমে।
• ব্রাউজারের নিজস্ব পথ: Chrome গুরুত্বপূর্ণ বাতিল খবর নিজের হালনাগাদে পাঠায় (CRLSets), Firefox সংকুচিত তালিকা (CRLite) চালু করেছে বলে জানা যায় — খুঁটিনাটি ব্রাউজারভেদে বদলায়। বড় CA-দের মধ্যে Let's Encrypt ২০২৪ সালে OCSP ছেড়ে CRL-এ ফেরার ঘোষণা দিয়েছিল।
• স্বল্পমেয়াদি certificate: সবচেয়ে কার্যকর সমাধান সম্ভবত মেয়াদ ছোট করা — বাতিল খবর না পৌঁছালেও ক্ষতির সময়সীমা ছোট।

Certificate Transparency (CT)

ধারণাটি সহজ: প্রতিটি সর্বজনীনভাবে বিশ্বস্ত certificate কয়েকটি প্রকাশ্য, শুধু-যোগ-করা-যায় এমন log-এ লিখতে হবে (মূল মান RFC 6962, ২০১৩)। Log certificate-টির জন্য একটি স্বাক্ষরিত প্রতিশ্রুতি (SCT) দেয়, যা certificate-এর ভেতরে বা handshake-এ থাকে; Chrome আর Safari নতুন certificate-এ SCT চায়। ফলে কোনো CA গোপনে আপনার domain-এর certificate দিতে পারে না — domain-এর মালিক log পর্যবেক্ষণ করে (crt.sh-এর মতো সেবা দিয়ে) নিজের নামের অপ্রত্যাশিত certificate ধরে ফেলতে পারেন। CT অপব্যবহার ঠেকায় না, কিন্তু দৃশ্যমান করে — আর দৃশ্যমানতাই CA-দের সৎ রাখে। সাথে DNS-এর CAA record দিয়ে আগেই বলে দেওয়া যায় কোন CA আপনার domain-এর certificate দিতে পারবে (পর্ব ৩৫)।

ACME আর Let's Encrypt — certificate হাতে নবায়নের দিন শেষ

২০১৫ সালের শেষে পরীক্ষামূলক আর ২০১৬ সালে পূর্ণভাবে চালু হয় বিনা খরচের CA Let's Encrypt; তার স্বয়ংক্রিয় protocol পরে মান হয় ACME নামে (RFC 8555, ২০১৯)। সার্ভারের একটি ছোট প্রোগ্রাম (যেমন certbot) প্রমাণ দেয় যে domain তার নিয়ন্ত্রণে — http-01 (port 80-এ একটি ফাইল), dns-01 (একটি TXT record, wildcard-এর জন্য দরকার) বা tls-alpn-01 — তারপর certificate নেয় আর নিজেই নবায়ন করে। এরপর ওয়েবে HTTPS-এর অংশ নাটকীয়ভাবে বেড়েছে বলে বিভিন্ন পরিমাপে দেখা যায়।

মেয়াদ ছোট হচ্ছে

একসময় certificate কয়েক বছরের জন্য পাওয়া যেত। ২০২০ সালে সর্বজনীন TLS certificate-এর সর্বোচ্চ মেয়াদ নামে ৩৯৮ দিনে (প্রথমে Apple-এর নীতি, পরে সবাই মেনে নেয়); Let's Encrypt শুরু থেকেই ৯০ দিন দিয়েছে। ২০২৫ সালে CA/Browser Forum ধাপে ধাপে মেয়াদ আরও কমানোর সিদ্ধান্ত নিয়েছে বলে জানা যায় — প্রথম ধাপ (প্রায় ২০০ দিন) ২০২৬ সাল থেকে কার্যকর, আর লক্ষ্য কয়েক বছরের মধ্যে দেড় মাসের কাছাকাছি। নির্দিষ্ট তারিখ আর সীমা Baseline Requirements-এর সর্বশেষ সংস্করণে দেখে নিন। শিক্ষা একটাই: certificate নবায়ন হাতে করার কাজ নয়, স্বয়ংক্রিয় করতে হবে, আর মেয়াদ শেষের সতর্কবার্তা monitoring-এ রাখতে হবে।

mTLS — দুই দিকেই পরিচয়পত্র

সাধারণ HTTPS-এ শুধু সার্ভার প্রমাণ দেয়; ব্যবহারকারী প্রমাণ দেন পরে, password বা OTP দিয়ে। Mutual TLS-এ সার্ভার handshake-এ CertificateRequest পাঠায়, আর ক্লায়েন্টও নিজের certificate ও CertificateVerify পাঠায়। কোথায় দেখবেন: microservice-গুলোর মধ্যে (service mesh প্রতিটি সার্ভিসকে স্বয়ংক্রিয়ভাবে স্বল্পমেয়াদি certificate দেয়), ব্যাংক ও আর্থিক প্রতিষ্ঠানের API, IoT যন্ত্র, অফিসের VPN বা Wi-Fi-তে যন্ত্রের পরিচয়। এখানে সাধারণত প্রতিষ্ঠানের নিজস্ব (private) CA থাকে — Web PKI নয়।

৮ · বাস্তবে HTTPS — HSTS, mixed content, termination আর interception

80 থেকে 443, আর প্রথম অনুরোধের ফাঁক

ব্যবহারকারী ঠিকানাবারে শুধু example.com লিখলে অনেক সময় প্রথম অনুরোধটি যায় http://-তে, port 80-এ, খোলা অবস্থায়। সার্ভার 301 দিয়ে HTTPS-এ পাঠায় (পর্ব ৩৬)। কিন্তু সেই প্রথম খোলা অনুরোধের মুহূর্তে পথের কোনো আক্রমণকারী redirect-টি মুছে দিয়ে ব্যবহারকারীকে HTTP-তেই রেখে দিতে পারে, নিজে সার্ভারের সাথে HTTPS-এ কথা বলে (এই কৌশলকে “SSL stripping” বলা হয়; প্রতিরক্ষা-সহ পর্ব ৫০)। সমাধান HSTS (HTTP Strict Transport Security, RFC 6797, ২০১২): সার্ভার HTTPS উত্তরে বলে দেয় “এই সাইটে আর কখনো HTTP নয়”.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age সেকেন্ডে: ৩১৫৩৬০০০ = ৩৬৫ × ৮৬৪০০, অর্থাৎ এক বছর। includeSubDomains সব sub-domain-এ প্রযোজ্য। শুধু HTTPS উত্তরের header মানা হয় — HTTP উত্তরেরটি নয়, নইলে আক্রমণকারী নিজেই বসিয়ে দিত।

Mixed content

HTTPS পাতার ভেতরে কোনো script বা ছবি http:// থেকে এলে তাকে বলে mixed content. একটি খোলা script পথে বদলে গেলে পুরো পাতা আক্রমণকারীর হাতে। তাই আধুনিক ব্রাউজার “সক্রিয়” mixed content (script) আটকায়, আর ছবির মতোগুলো https-এ বদলে নেয় বা আটকায় — নীতি ব্রাউজারভেদে ভিন্ন। সমাধান: সব resource HTTPS-এ, চাইলে Content-Security-Policy-তে upgrade-insecure-requests.

TLS termination

বড় সাইটে TLS সাধারণত সামনের load balancer, reverse proxy বা CDN-এর edge-এ খোলা হয় — TLS termination (পর্ব ৩৮; data center-এর load balancer পর্ব ৫২-তে)। সুবিধা: certificate এক জায়গায়, CPU-ভারী কাজ আলাদা যন্ত্রে, HTTP দেখে routing আর cache. মনে রাখুন: edge থেকে origin পর্যন্ত পথও আবার TLS (প্রায়ই mTLS) দিয়ে এনক্রিপ্ট করা উচিত, আর edge-এর হাতে সাইটের key থাকে — সেই প্রতিষ্ঠানকে বিশ্বাস করতে হয়।

ECH — নামটিও লুকানো

TLS 1.3-এ certificate লুকানো গেলেও SNI-তে নাম খোলা। ECH (Encrypted Client Hello) আসল ClientHello এনক্রিপ্ট করে একটি বাইরের ClientHello-র ভেতরে পাঠায়, যার SNI-তে থাকে একটি সাধারণ “public name” (যেমন CDN-এর)। Key আসে DNS-এর HTTPS record থেকে (পর্ব ৩৫, ৩৭)। কিছু ব্রাউজার আর CDN এটি চালু করেছে; মানের বর্তমান অবস্থা IETF-এ যাচাই করে নিন। ECH কাজে লাগে যখন অনেক সাইট একই public name-এর পেছনে থাকে আর DNS-ও এনক্রিপ্টেড থাকে।

TLS interception — অফিসের proxy আর antivirus

কিছু প্রতিষ্ঠানের নিরাপত্তা-যন্ত্র আর কিছু antivirus এনক্রিপ্টেড ট্রাফিক “দেখতে” চায়। কৌশল: কম্পিউটারের trust store-এ নিজেদের একটি root CA বসানো, তারপর মাঝখানে বসে প্রতিটি সাইটের জন্য তাৎক্ষণিক certificate বানানো — কাঠামোগতভাবে একটি অনুমোদিত MITM. ঝুঁকি গবেষণায় নথিভুক্ত: অনেক পণ্য বাইরের certificate ঠিকমতো যাচাই করে না বা দুর্বল TLS চালায়, ফলে ব্যবহারকারী কম সুরক্ষিত হন; সেই root CA-র key ফাঁস হলে সব যন্ত্র ঝুঁকিতে; আর গোপনীয়তার প্রশ্ন। প্রতিরক্ষার দৃষ্টিতে: শুধু লিখিত নীতি আর ব্যবহারকারীকে জানিয়ে, সংবেদনশীল বিভাগ বাদ রেখে, পণ্যের TLS যাচাই নিয়মিত পরীক্ষা করে। নিজের যন্ত্রে certificate-এর issuer-এ অপরিচিত নাম (যেমন কোনো antivirus) দেখলে বুঝবেন কেউ মাঝে আছে।

৯ · AI-এর যুগে TLS — কনফিগারেশন, ত্রুটি আর যাচাই

“nginx-এ HTTPS চালু করার config লিখে দিন” — AI মুহূর্তে লিখে দেয়। কিন্তু TLS নিয়ে ইন্টারনেটের পুরোনো লেখা প্রচুর, আর AI প্রায়ই সেগুলো মিশিয়ে ফেলে। চেনা ভুলগুলো:

AI-এর TLS-পরামর্শ চালু করার আগে — চেকলিস্ট

• সংস্করণ আর cipher তালিকা একটি হালনাগাদ, পরিচিত উৎসের সাথে মিলিয়েছি; TLS 1.0/1.1 বা SSL কোথাও নেই
• কোনো ধাপে certificate যাচাই বন্ধ করা (-k, verify=False) নেই — আর থাকলে আসল কারণ খুঁজেছি
• openssl s_client দিয়ে নিজের সার্ভারে শিকল, নাম আর মেয়াদ নিজে দেখেছি; ব্রাউজার ছাড়া অন্য ক্লায়েন্ট (curl) থেকেও পরীক্ষা করেছি
• RFC নম্বর আর সাল rfc-editor.org-এ মিলিয়েছি; ভবিষ্যতের নিয়ম (মেয়াদ, ব্রাউজার-নীতি) অফিসিয়াল সূত্রে দেখেছি
• Private key কোথাও শেয়ার করিনি; স্বয়ংক্রিয় নবায়ন আর মেয়াদ-শেষের সতর্কবার্তা চালু করেছি