TLS বাস্তবে — handshake, ভালো configuration আর certificate সামলানো

১ · Handshake জানা আর TLS চালানো — দুটি আলাদা কাজ

একটি কাল্পনিক অনলাইন বাজারের কথা ভাবুন। এক শুক্রবার সকালে হঠাৎ অর্ডার শূন্য। ব্রাউজারে লাল সতর্কবার্তা, মোবাইল অ্যাপে শুধু “সংযোগ ব্যর্থ”. কোনো হ্যাকার আসেনি, কোনো cipher ভাঙেনি। একটি certificate-এর মেয়াদ রাত ১২টায় শেষ হয়েছে, আর যিনি এটি নবায়ন করতেন তিনি ছয় মাস আগে চাকরি ছেড়েছেন।

TLS নিয়ে বাস্তবের বেশিরভাগ সমস্যা এমনই। গণিত প্রায় কখনো ভাঙে না, ভাঙে কাজের প্রক্রিয়া। এই পর্ব তাই অপারেটরের চোখে লেখা: যিনি server চালান, যাঁর ফোনে রাত ৩টায় alert আসে।

Handshake-এর বার্তা, key schedule আর X.509-এর খুঁটিনাটি এখানে আবার শেখানো হবে না। সেগুলো পাবেন কম্পিউটার নেটওয়ার্ক কোর্সের TLS আর HTTPS পর্বে। Key exchange দেখুন পর্ব ১০-এ, certificate আর বিশ্বাসের শিকল পর্ব ১১-এ। এখানে শুধু এক লাইনের স্মরণিকা: HTTPS মানে TLS-এর ভেতর দিয়ে HTTP, আর TLS দেয় গোপনীয়তা, অখণ্ডতা আর server-এর পরিচয়। প্রথম দুটির কথা আপনি পর্ব ০২-এর CIA triad-এ দেখেছেন।

২ · TLS 1.3 handshake — অপারেটরের চোখে

TLS 1.3 প্রথম আসে RFC 8446-এ (২০১৮). জুলাই ২০২৬-এ RFC 9846 সেটিকে প্রতিস্থাপন করেছে, তবে version একই আছে, বদল ছোট আর পুরোনোর সাথে মানানসই. নিচের ডায়াগ্রামে প্রতিটি ধাপে দেখুন কে কী দেখতে পাচ্ছে, আর অপারেটর হিসেবে সেখানে আপনার কী খেয়াল রাখা দরকার। উদাহরণের সাইট shop.example.com.

TLS 1.2 থেকে কী বদলেছে

৩ · Version, cipher আর forward secrecy — কী রাখবেন, কী ছাঁটবেন

পুরোনো জামা আলমারিতে জমিয়ে রাখলে ক্ষতি নেই, কিন্তু পুরোনো cipher জমিয়ে রাখলে ক্ষতি আছে। Server-এ একটি দুর্বল বিকল্প চালু থাকলে পথের আক্রমণকারী সংযোগকে সেদিকে ঠেলে দেওয়ার চেষ্টা করতে পারে। তাই নিয়মটি পর্ব ০৩-এর attack surface কমানোর নীতি: যা দরকার নেই, তা বন্ধ।

যা অবসরে গেছে

সুপারিশকৃত ভিত্তি

নিজে বাছাই না করে পরিচিত নির্দেশিকা অনুসরণ করাই নিরাপদ। তিনটি উৎস মিলিয়ে দেখুন, আর ব্যবহারের আগে সর্বশেষ সংস্করণ যাচাই করুন:

• Mozilla-র SSL Configuration Guidelines: এই পর্ব লেখার সময় version 6.0 দেখা গেছে। “Modern” প্রোফাইল শুধু TLS 1.3, আর “Intermediate” প্রোফাইল TLS 1.2 ও 1.3, যেখানে TLS 1.2-তে শুধু ECDHE-র সাথে AES-GCM বা ChaCha20-Poly1305 (পর্ব ০৮-এর AEAD). সাধারণ ওয়েবসাইটের জন্য Intermediate-ই প্রচলিত শুরু। নির্দেশিকার পুরোনো wiki পাতাটি সরে গেছে, তাই ssl-config.mozilla.org-এর generator থেকে নিজের software version অনুযায়ী মিলিয়ে নিন।
• NIST SP 800-52 Rev. 2 (২০১৯): মার্কিন সরকারি ব্যবস্থার নির্দেশিকা। সব সরকারি TLS server আর client-এ TLS 1.2 সমর্থন চায়, আর ২০২৪ সালের ১ জানুয়ারির মধ্যে TLS 1.3 সমর্থনের পরিকল্পনার কথা বলে। ২০২৬ সালে NIST এটি পর্যালোচনায় মতামত চেয়েছে আর সংশোধনের কথা জানিয়েছে, তাই নতুন সংস্করণ এসেছে কি না দেখে নিন। বাংলাদেশে এটি বাধ্যতামূলক নয়, তবে ভালো মানদণ্ড।
• RFC 9325 (BCP 195, ২০২২): IETF-এর TLS ব্যবহারের সুপারিশ।

Forward secrecy — আজকের রেকর্ড কাল খোলা যাবে না

ধরুন কেউ আজ আপনার সব এনক্রিপ্টেড ট্রাফিক রেকর্ড করে রাখছে। দুই বছর পরে আপনার server-এর পুরোনো backup থেকে private key পাওয়া গেল। Static RSA-তে session-এর গোপন মান ওই key দিয়েই এনক্রিপ্ট হয়ে পথে গিয়েছিল, তাই পুরোনো সব রেকর্ড খুলে যায়। ECDHE-তে প্রতিটি সংযোগের জন্য অস্থায়ী চাবি তৈরি হয় আর কাজ শেষে মুছে যায়; certificate-এর key শুধু পরিচয় প্রমাণে স্বাক্ষর করে। তাই key চুরি গেলে ভবিষ্যতে নকল server সাজা সম্ভব হলেও পুরোনো রেকর্ড খোলে না।

দুটি ফাঁক মনে রাখুন:

• Session ticket-এর চাবি: এই চাবি দীর্ঘদিন একই থাকলে এবং চুরি গেলে, সেই চাবিনির্ভর পুরোনো session ঝুঁকিতে পড়তে পারে। বিশেষ করে TLS 1.2-তে এটি গুরুত্বপূর্ণ। হয় ticket বন্ধ রাখুন, নয় চাবি নিয়মিত ঘোরান।
• 0-RTT: এই early data-র forward secrecy দুর্বল আর এটি replay হতে পারে। তাই না বুঝে চালু করবেন না, আর চালু করলে শুধু নিরাপদে পুনরাবৃত্তিযোগ্য অনুরোধে সীমিত রাখুন।

৪ · ভালো configuration — nginx, HSTS আর নিজের server যাচাই

নিচের উদাহরণটি Mozilla-র Intermediate ধারণা অনুসরণ করে লেখা একটি nginx block. nginx শুধু একটি উদাহরণ; Apache, HAProxy বা আপনার load balancer-এ একই ধারণা অন্য নামে পাবেন। Path আর নাম আপনার নিজের মতো বদলে নিন।

# উদাহরণ: নিজের server-এর জন্য। সরাসরি কপি না করে আপনার nginx
# আর OpenSSL version অনুযায়ী generator থেকে মিলিয়ে নিন।
server {
    listen 80;
    listen [::]:80;
    server_name shop.example.com;

    # ACME http-01 ব্যবহার করলে এই path খোলা রাখতে হবে
    location /.well-known/acme-challenge/ { root /var/www/acme; }
    location / { return 301 https://shop.example.com$request_uri; }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;                      # nginx 1.25.1 বা নতুন
    server_name shop.example.com;

    ssl_certificate     /etc/ssl/shop/fullchain.pem;   # intermediate-সহ
    ssl_certificate_key /etc/ssl/shop/privkey.pem;     # শুধু root পড়বে

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;       # চাবি ঘোরানোর ব্যবস্থা না থাকলে বন্ধ

    # শুরুতে ছোট max-age; সব sub-domain HTTPS হলে তবে বাড়ান
    add_header Strict-Transport-Security "max-age=300" always;

    # আপনার CA OCSP দিলে তবেই:
    # ssl_stapling on;
    # ssl_stapling_verify on;

    # hybrid post-quantum key exchange, OpenSSL 3.5 বা নতুন লাগে:
    # ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
}

HSTS আর preload — ধাপে ধাপে

HSTS (RFC 6797, ২০১২) ব্রাউজারকে বলে, এই সাইটে এতদিন শুধু HTTPS. ধারণাটি নেটওয়ার্ক কোর্সে আছে, এখানে আছে চালু করার ক্রম, কারণ ভুল করলে পুরোনো sub-domain বন্ধ হয়ে যেতে পারে।

1. সব domain আর sub-domain-এর তালিকা বানান, ভেতরের যন্ত্রসহ। Mixed content দূর করুন।
2. max-age=300 (৫ মিনিট) দিয়ে শুরু করে কিছুদিন দেখুন।
3. এক সপ্তাহ (৬০৪৮০০), তারপর এক মাস (২৫৯২০০০), তারপর এক বছর (৩১৫৩৬০০০) করুন। Mozilla-র নির্দেশিকা দুই বছর (৬৩০৭২০০০) বলে।
4. প্রস্তুত হলে includeSubDomains যোগ করুন।
5. দীর্ঘমেয়াদে নিশ্চিত হলে তবেই preload ভাবুন।

hstspreload.org-এর বর্তমান শর্ত অনুযায়ী বৈধ certificate, HTTP থেকে HTTPS-এ redirect, সব sub-domain-এ HTTPS, আর base domain-এর header-এ অন্তত এক বছরের max-age, includeSubDomains ও preload থাকতে হয়। সেখানে স্পষ্ট বলা আছে, তালিকা থেকে বের হওয়া সহজ নয়: বদল পৌঁছাতে মাসের পর মাস লাগতে পারে। সিদ্ধান্তটি তাই দরজায় স্থায়ী তালা লাগানোর মতো ভেবে নিন।

নিজের server যাচাই — openssl s_client

Configuration ফাইল যা বলে আর client যা পায়, দুটো এক নাও হতে পারে। তাই নিজের server-এ বাইরে থেকে দেখুন। নিচের কমান্ডগুলো শুধু নিজের domain-এ বা নিজের অনুমোদিত সিস্টেমে চালাবেন।

# উদাহরণ: shop.example.com-এর জায়গায় আপনার নিজের domain বসান।
# ১. সংক্ষেপে: version, cipher আর যাচাইয়ের ফল
openssl s_client -connect shop.example.com:443 -servername shop.example.com \
  -verify_hostname shop.example.com -verify_return_error -brief </dev/null

# ২. পাঠানো certificate-এর নাম আর মেয়াদ
openssl s_client -connect shop.example.com:443 -servername shop.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -enddate

# ৩. ৩০ দিনের (2592000 সেকেন্ড) মধ্যে মেয়াদ শেষ হবে কি না
openssl x509 -in fullchain.pem -noout -checkend 2592000

নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে (কমান্ড ১, হাতে সাজানো; কোনো আসল সাইটের নয়):

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = shop.example.com
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Verified peername: shop.example.com
Peer Temp Key: X25519, 253 bits
DONE

কমান্ড ৩ এই পর্ব লেখার সময় একটি পরীক্ষার ফোল্ডারে বানানো self-signed certificate-এ (মেয়াদ ৯০ দিন) চালিয়ে দেখা হয়েছে। ৩০ দিনের সীমায় আউটপুট Certificate will not expire, exit code 0. ১০০ দিনের সীমায় (-checkend 8640000) আউটপুট Certificate will expire, exit code 1. এই exit code-ই script বা monitoring-এ কাজে লাগে।

খেলনা auditor — grade আর কারণ

আসল scanner অন্য সিস্টেমে যোগাযোগ করে, তাই এখানে তা নেই। নিচের auditor শুধু memory-র ভেতরের খেলনা config object পড়ে। নম্বরগুলো শেখার জন্য বানানো, কোনো মান নয়। নিয়ম বদলে দেখুন grade কীভাবে বদলায়।

// খেলনা config object, কোনো real server-এ যোগাযোগ নেই (শুধু ধারণার জন্য)
const sites = [
  { name: 'shop.example.com', versions: ['TLSv1.2', 'TLSv1.3'],
    ciphers: ['ECDHE-RSA-AES128-GCM-SHA256'], hsts: 63072000, chainOk: true },
  { name: 'portal.example.com', versions: ['TLSv1.0', 'TLSv1.2'],
    ciphers: ['ECDHE-RSA-AES128-GCM-SHA256', 'AES128-SHA'], hsts: 0, chainOk: true },
  { name: 'legacy.example.com', versions: ['SSLv3', 'TLSv1.2'],
    ciphers: ['RC4-SHA'], hsts: 86400, chainOk: false },
];
// প্রতিটি নিয়ম: bad(site) সত্য হলে কত নম্বর কাটা যাবে আর কেন
const rules = [
  { cost: 60, why: 'SSLv3 on (retired, RFC 7568)', bad: s => s.versions.includes('SSLv3') },
  { cost: 25, why: 'TLS 1.0/1.1 on (retired, RFC 8996)',
    bad: s => s.versions.some(v => v === 'TLSv1.0' || v === 'TLSv1.1') },
  { cost: 10, why: 'TLS 1.3 off', bad: s => !s.versions.includes('TLSv1.3') },
  { cost: 40, why: 'RC4 cipher on', bad: s => s.ciphers.some(c => c.includes('RC4')) },
  { cost: 20, why: 'cipher without forward secrecy',
    bad: s => s.ciphers.some(c => !c.startsWith('ECDHE-') && !c.startsWith('DHE-')) },
  { cost: 40, why: 'incomplete certificate chain', bad: s => !s.chainOk },
  { cost: 10, why: 'HSTS missing or under 1 year', bad: s => s.hsts < 31536000 },
];
const grade = p => p >= 90 ? 'A' : p >= 70 ? 'B' : p >= 50 ? 'C' : 'F';
for (const s of sites) {
  const hits = rules.filter(r => r.bad(s));
  const points = Math.max(0, 100 - hits.reduce((sum, r) => sum + r.cost, 0));
  console.log(`${s.name}: ${points}/100, grade ${grade(points)}`);
  for (const r of hits) console.log(`   -${r.cost}  ${r.why}`);
}

৫ · Certificate সামলানো — automation, monitoring আর মেয়াদ শেষের বিভ্রাট

Certificate দারোয়ানের পরিচয়পত্রের মতো: মেয়াদ শেষ হলে লোকটি সৎ থাকলেও গেট দিয়ে ঢুকতে দেওয়া হবে না। প্রকৌশলে এই ব্যর্থতা অদ্ভুত, কারণ সময়টি আগে থেকেই জানা, তবু প্রতি বছর বড় বড় বিভ্রাট ঘটে।

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

CA/Browser Forum ২০২৫ সালের এপ্রিলে ballot SC-081 গ্রহণ করে। Baseline Requirements-এ এখন যে সূচি দেখা যায় (অক্টোবর ২০২৬-এ মিলিয়ে দেখা):

এই সূচি সর্বজনীনভাবে বিশ্বস্ত TLS certificate-এর জন্য; নিজের private CA-তে আপনার নিজের নীতি চলে। সূচি বদলাতে পারে, তাই পরিকল্পনার আগে সর্বশেষ Baseline Requirements দেখে নিন। কিছু CA নিজেরাও আরও ছোট মেয়াদের পরিকল্পনা জানিয়েছে; নিজের CA-র ঘোষণা পড়ুন। মেয়াদ ছোট করার একটি কারণ revocation-এর দুর্বলতা: বাতিলের খবর সবার কাছে না পৌঁছালেও চুরি যাওয়া key-র ক্ষতি কম সময়ে থামে। কিছু CA এখন OCSP ছেড়ে CRL-এ গেছে, তাই stapling সেটিং আপনার CA অনুযায়ী দেখে নিন।

Automation-এর হিসাব

ধরা যাক ১২০টি certificate, হাতে প্রতিবার ৩০ মিনিট, আর মেয়াদের ২/৩ পার হলে নবায়ন। প্রতি ১০০ বার হাতের কাজে ২ বার ভুল হয়, এটি শেখার জন্য ধরে নেওয়া সংখ্যা, কোনো পরিমাপ নয়।

// ধরে নেওয়া সংখ্যা: 120 certificate, হাতে প্রতিবার 30 মিনিট,
// প্রতি 100 বার হাতের নবায়নে 2 বার কিছু ভুল হয়। মেয়াদের 2/3 পার হলে নবায়ন।
const CERTS = 120, MINUTES = 30, MISS_RATE = 0.02;
const lifetimes = [398, 200, 100, 47];
console.log('max_days  renew_every  per_year  hours/yr  expected_misses');
for (const days of lifetimes) {
  const every = days * 2 / 3;
  const perYear = 365 / every;
  const total = perYear * CERTS;
  const hours = total * MINUTES / 60;
  const misses = total * MISS_RATE;
  console.log(
    String(days).padStart(8) + every.toFixed(1).padStart(13) +
    perYear.toFixed(2).padStart(10) + hours.toFixed(0).padStart(10) +
    misses.toFixed(1).padStart(17));
}

কেন ভোলা certificate-ই বিভ্রাট ঘটায়

• মালিক নেই: যিনি জানতেন তিনি চলে গেছেন, alert যায় পুরোনো mailbox-এ।
• তালিকার বাইরে: load balancer, VPN, firewall, ভেতরের API, ক্যামেরা, বা অ্যাপে বসানো certificate. Certificate Transparency log আর নিয়মিত নিজের সিস্টেমের তালিকা মেলানো এখানে সাহায্য করে।
• নবায়ন হলো, বসল না: নতুন ফাইল disk-এ আছে, কিন্তু server reload হয়নি।
• Automation নিজেই থেমে গেছে: firewall বা WAF নিয়ম বদলে ACME-র যাচাই আটকে যায়।
• সতর্কতা শুধু মেয়াদের ওপর: নবায়ন ব্যর্থতার alert নেই, তাই সমস্যা জানা যায় অনেক দেরিতে।

প্রকাশিত দুটি উদাহরণ দেখুন। ডিসেম্বর ২০১৮-তে Ericsson-এর network software-এর একটি মেয়াদোত্তীর্ণ certificate কয়েক দেশের মোবাইল সেবায় বিঘ্ন ঘটিয়েছিল বলে প্রতিষ্ঠানটির প্রাথমিক বিশ্লেষণ ও সংবাদে জানা যায়। Equifax (২০১৭) নিয়ে অংশ ৭-এ আসছি। নিচের ঘটনাটি কাল্পনিক, কিন্তু এমন ঘটনা বাস্তবে ঘটে।

Monitoring — simulated তারিখে

ভালো monitoring তিনটি কাজ করে: মেয়াদ দেখে, নবায়ন ব্যর্থতা দেখে, আর মালিকহীন certificate ধরে। নিচের monitor একটি নির্দিষ্ট তালিকা আর একটি কাল্পনিক “আজ” (১৩ ডিসেম্বর ২০২৬) ধরে চলে; আসল সময় বা network ব্যবহার করে না।

// simulated clock: আসল তারিখ ব্যবহার হয় না। তালিকাটিও খেলনা।
const TODAY = Date.UTC(2026, 11, 13);      // 2026-12-13
const DAY = 86400000;
const inventory = [
  { name: 'shop.example.com',  notAfter: [2026, 12, 20], owner: 'web-team', renewOk: false },
  { name: 'api.example.com',   notAfter: [2027, 2, 10],  owner: 'api-team', renewOk: true },
  { name: 'vpn.example.com',   notAfter: [2026, 12, 29], owner: 'net-team', renewOk: true },
  { name: 'admin.example.com', notAfter: [2026, 12, 9],  owner: 'web-team', renewOk: false },
  { name: 'old.example.com',   notAfter: [2027, 1, 5],   owner: '',         renewOk: true },
];
function status(left) {
  if (left < 0) return 'EXPIRED';
  if (left <= 7) return 'CRITICAL';
  if (left <= 30) return 'WARNING';
  return 'OK';
}
const rows = inventory.map(c => {
  const [y, m, d] = c.notAfter;
  const left = Math.floor((Date.UTC(y, m - 1, d) - TODAY) / DAY);
  const notes = [];
  if (!c.renewOk) notes.push('last auto-renew FAILED');
  if (!c.owner) notes.push('no owner');
  return { ...c, left, st: status(left), notes };
});
rows.sort((a, b) => a.left - b.left);
for (const r of rows) {
  console.log(r.st.padEnd(9) + String(r.left).padStart(4) + 'd  ' +
    r.name.padEnd(19) + r.notes.join(', '));
}
const page = rows.filter(r => r.st === 'EXPIRED' || r.st === 'CRITICAL').length;
console.log(`page on-call now: ${page}, of ${rows.length} certificates`);

৬ · mTLS আর TLS termination — proxy-র পেছনে কী খোলা থাকে

TLS কোথায় শেষ হয়

বেশিরভাগ বড় সিস্টেমে TLS app server পর্যন্ত যায় না। সামনের reverse proxy, load balancer বা CDN সেটি খুলে ফেলে, একে বলে TLS termination. সুবিধা অনেক: certificate এক জায়গায়, HTTP দেখে routing, API gateway বা WAF-এর কাজ। কিন্তু একটি বিষয় ভোলা চলে না: TLS খোলা মানে proxy-র memory-তে পুরো ডেটা খোলা।

একটি login অনুরোধ এই পথে কীভাবে যায়, ধাপে ধাপে দেখুন। ডেটার মানগুলো কাল্পনিক।

mTLS — সার্ভিসে সার্ভিসে পরিচয়পত্র

সাধারণ TLS-এ শুধু server পরিচয় দেয়। mTLS-এ client-ও certificate দেখায়। অফিসের গেটে দারোয়ান আপনার কার্ড দেখছেন, আপনিও দারোয়ানের পোশাক আর কার্ড দেখছেন। ভেতরের API-তে password বা স্থায়ী token-এর বদলে এটি চমৎকার, কারণ private key পথে যায় না।

অপারেটরের চোখে কয়েকটি কথা:

• Private CA ব্যবহার করুন। নিজের network-এর ভেতরের পরিচয়ের জন্য এটিই স্বাভাবিক, আর এর key খুব সাবধানে রাখতে হয় (Secrets ও KMS). সর্বজনীন certificate-এ client authentication ব্যবহার এখন ঝুঁকিপূর্ণ: Chrome-এর root program নীতির জেরে সর্বজনীন CA-গুলো ২০২৬ থেকে ধাপে ধাপে এই ব্যবহার সরিয়ে নিচ্ছে বলে CA-দের ঘোষণায় জানা যায়। তারিখ নিজের CA থেকে মিলিয়ে নিন।
• মেয়াদ ছোট, নবায়ন স্বয়ংক্রিয়। Service mesh বা SPIFFE-র মতো ব্যবস্থা ঘণ্টা বা দিনের মেয়াদে certificate দিতে পারে।
• পরিচয় মানে অনুমতি নয়। mTLS বলে “এটি billing সার্ভিস”; “billing কি এই ডেটা পড়তে পারে?” সেই প্রশ্ন authorization-এর (পর্ব ১৯)।
• Trust store সীমিত রাখুন। যে CA-কে client হিসেবে মানছেন, সে CA থেকে পাওয়া সব certificate ঢুকতে পারে। তাই শুধু chain নয়, নামও যাচাই করুন।

৭ · TLS inspection, SNI আর ECH — দেখা আর না-দেখার টানাপোড়েন

TLS inspection

প্রতিষ্ঠানের নিরাপত্তা দল বলে, malware-ও HTTPS ব্যবহার করে, না দেখলে ধরব কীভাবে? সমাধান হিসেবে TLS inspection: প্রতিষ্ঠানের নিজের root CA সব অফিস-যন্ত্রের trust store-এ বসানো হয়, আর একটি proxy দুই দিকের সংযোগ আলাদা করে খুলে দেখে। কাঠামোগতভাবে এটি একটি অনুমোদিত MITM. TLS 1.3-এ পুরোনো “passive decrypt” চলে না, তাই এই সক্রিয় proxy বা endpoint-এ নজরদারিই প্রধান পথ।

যদি করতেই হয়: লিখিত নীতি আর কর্মীদের জানানো, ব্যাংকিং ও স্বাস্থ্যের মতো শ্রেণি বাদ, CA key হার্ডওয়্যারে রাখা, পণ্যের outbound TLS পরীক্ষা, আর শুধু নিজের প্রতিষ্ঠানের যন্ত্রে। আইনি দিক দেশভেদে আলাদা; এটি আইনি পরামর্শ নয়, প্রতিষ্ঠানের আইনজীবীর সাথে কথা বলুন (পর্ব ০৬)।

SNI আর ECH — একটি সংক্ষিপ্ত নোট

একই IP-তে অনেক সাইট থাকে, তাই client SNI-তে নাম বলে, আর সেটি খোলা। ECH (RFC 9849, মার্চ ২০২৬) আসল নামসহ ClientHello-র গোপন অংশ এনক্রিপ্ট করে; বাইরের অংশে থাকে একটি সাধারণ public_name. Key আসে DNS থেকে, তাই DNS-ও এনক্রিপ্টেড না হলে লাভ কমে। সমর্থন ব্রাউজার আর সেবাভেদে আলাদা।

অপারেটরের জন্য অর্থ: নিজের সাইটে চালু করতে হলে DNS-এর HTTPS record আর server-এর সমর্থন লাগবে। আবার প্রতিষ্ঠানের যে filter SNI দেখে সিদ্ধান্ত নেয়, ভবিষ্যতে সেটি কিছু ট্রাফিকে অন্ধ হতে পারে, তাই শুধু SNI-র ওপর নির্ভর করা নকশা এখনই ভেবে দেখা ভালো। ব্যবহারকারীর গোপনীয়তা আর প্রতিষ্ঠানের দৃশ্যমানতা, দুটোই বৈধ লক্ষ্য; সিদ্ধান্ত নিতে হয় ঝুঁকি মেপে।

৮ · সাধারণ ভুল আর ইতিহাসের শিক্ষা — verify=False, Heartbleed, POODLE

সাধারণ ভুলের তালিকা

verify=False — ত্রুটি লুকানোর সবচেয়ে বিপজ্জনক সমাধান

রাত ২টা। ভেতরের API-তে CERTIFICATE_VERIFY_FAILED এল। Stack Overflow বা AI বলল, একটি flag যোগ করুন, সব ঠিক হয়ে যাবে। সত্যিই ঠিক হয়ে যায়, আর সেখানেই বিপদ। ত্রুটিটি ধোঁয়ার অ্যালার্ম ছিল; আপনি ব্যাটারি খুলে নিলেন।

# উদাহরণ: চালানোর জন্য নয়। api.example.com একটি নমুনা নাম।
import requests

# অ্যান্টি-প্যাটার্ন: যাচাই বন্ধ। কোনো নকল server-ও গৃহীত হবে।
r = requests.get("https://api.example.com/health", verify=False)

# ঠিক পথ: ভেতরের CA-কে স্পষ্টভাবে বিশ্বাস করা
r = requests.get("https://api.example.com/health",
                 verify="/etc/ssl/internal-ca.pem", timeout=5)

একই ভুলের অন্য রূপ: curl -k, Node.js-এর rejectUnauthorized: false, আর NODE_TLS_REJECT_UNAUTHORIZED=0. নিচের খেলনা client দেখায় যাচাই থাকা আর না থাকার পার্থক্য। এখানে কোনো network নেই।

// খেলনা client: কোনো network নেই, certificate মানে সাধারণ object
const TODAY = '2026-12-13';
const trustStore = ['Example Root CA'];
const certs = [
  { label: 'real server',    san: ['shop.example.com'], root: 'Example Root CA', notAfter: '2027-03-13' },
  { label: 'expired',        san: ['shop.example.com'], root: 'Example Root CA', notAfter: '2026-12-09' },
  { label: 'wrong name',     san: ['mail.example.com'], root: 'Example Root CA', notAfter: '2027-03-13' },
  { label: 'self-signed',    san: ['shop.example.com'], root: 'Unknown Lab CA',  notAfter: '2027-03-13' },
];
function nameMatches(host, pattern) {
  if (!pattern.startsWith('*.')) return host === pattern;
  const parts = host.split('.');               // wildcard: ঠিক একটি label
  return parts.slice(1).join('.') === pattern.slice(2);
}
function verify(cert, host, verifyOn) {
  if (!verifyOn) return 'CONNECT (nothing checked)';
  if (!trustStore.includes(cert.root)) return 'REFUSE: untrusted issuer';
  if (cert.notAfter < TODAY) return 'REFUSE: expired';
  if (!cert.san.some(p => nameMatches(host, p))) return 'REFUSE: hostname mismatch';
  return 'CONNECT (verified)';
}
const host = 'shop.example.com';
for (const flag of [true, false]) {
  console.log(`verify=${flag ? 'True' : 'False'}`);
  for (const c of certs) {
    console.log('  ' + c.label.padEnd(13) + verify(c, host, flag));
  }
}

Heartbleed আর POODLE — দুই ধরনের ব্যর্থতা

দুটি ঘটনাই ২০১৪ সালের। এখানে শুধু প্রকাশিত প্রতিবেদনের স্তরে, প্রতিরক্ষার শিক্ষা হিসেবে দেখুন।

৯ · Checklist আর AI-এর যুগে TLS

অপারেটরের TLS checklist

• TLS 1.3 চালু; TLS 1.2 শুধু ECDHE আর AEAD; পুরোনো সব বন্ধ
• Load balancer, VPN আর appliance-ও একই audit-এ আছে
• সব certificate-এর তালিকা আছে, প্রতিটির বর্তমান মালিকসহ
• নবায়ন স্বয়ংক্রিয়, reload-সহ, আর ব্যর্থ হলে প্রথম দিনেই alert
• বাইরে থেকে মেয়াদ, chain আর নামের monitoring চলছে
• HSTS ধাপে ধাপে চালু; preload-এর সিদ্ধান্ত ভেবে নেওয়া
• Private key-র permission শক্ত, repo-তে নেই; ফাঁস হলে বদলানোর runbook আছে
• Proxy-র পেছনের পথ এনক্রিপ্টেড, আর log-এ secret নেই
• Client কোডে verify=False বা curl -k নেই; CI তা খোঁজে
• OpenSSL বা TLS library-র version জানা, patch-এর পরিকল্পনা আছে

AI কোথায় ভুল করে

AI-এর পরামর্শ বসানোর আগে

• প্রম্পটে কোনো key, token বা ব্যক্তিগত তথ্য নেই
• প্রতিটি CVE, RFC আর মেয়াদের নিয়ম প্রাথমিক উৎসে পড়েছি
• পরিবর্তন আগে পরীক্ষার পরিবেশে, তারপর production-এ
• Diff পড়েছি: কোনো যাচাই বা সতর্কতা কি বন্ধ হলো?
• Rollback পথ জানি, আর চূড়ান্ত সিদ্ধান্ত একজন মানুষের