Foundationপ্রথম নীতি থেকে
LEVEL 7লেসন ১৭/২২রিসার্চ-লেভেল১ ঘণ্টা ৫ মিনিট

TLS 1.3 — handshake, certificate chain, আর ভরসার গণিত

TLS 1.3 Handshake and Certificate Chain

TCP connection হলেই TLS শুরু — এক রাউন্ড-ট্রিপে key exchange, certificate chain যাচাই, আর traffic keys; TLS 1.3 কী দেয়, কী দেয় না, আর 0-RTT-র ফাঁদ কোথায়।

এই লেসন শেষে আপনি পারবেন

  • TLS-র তিনটা guarantee — confidentiality, integrity, authenticity — আলাদা করে ব্যাখ্যা করতে পারবেন, আর anonymity বা availability কেন এই তালিকায় নেই তা দেখাতে পারবেন
  • TLS 1.3-এর one round-trip handshake-এর ধাপগুলো trace করতে পারবেন — ClientHello key_share থেকে ECDHE shared secret, HKDF, traffic keys — math proof ছাড়া conceptual level-এ
  • 0-RTT resumption-এর সুবিধা আর replay danger উভয়ই বর্ণনা করে বলতে পারবেন কোন request 0-RTT-তে পাঠানো নিরাপদ, কোনটা অনিরাপদ
  • Certificate chain walk করতে পারবেন — leaf ← intermediate ← root — hostname/SAN verification-সহ, আর trust store-এর ভূমিকা বুঝিয়ে দিতে পারবেন
  • Mixed-content warning কেন ঘটে, downgrade protection কীভাবে কাজ করে — বাস্তব openssl observation-এর সাথে মিলিয়ে ব্যাখ্যা করতে পারবেন

আগে যা বোঝা থাকা দরকার

আগে এটা বুঝি

আপনি address বুঝেছেন (DHCP), packet route হয়েছে, TCP connection হয়েছে। এখন browser-এ https:// লিখলেন — আর TCP handshake শেষ হওয়ার মাইক্রোসেকেন্ড পরে, প্রথম HTTP byte যাওয়ার আগেই, দুই পক্ষ crypto-র একটা আচার সম্পন্ন করে: TLS handshake।

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

  1. line-এ বসে সব packet পড়লেও? (confidentiality)
  2. মাঝপথে bytes বদলে দিলেও? (integrity)
  3. server-টা আসলে যাকে বলছে, সে-ই তো? (authenticity)

TLS 1.3 (RFC 8446, 2018) এই উত্তরগুলো দেয় এক round-trip-এ — পূর্বসূরি 1.2 লাগাত দুইটা; আর কিছু ক্ষেত্রে শূন্য — দুর্দান্ত গতি, সাথে একটা সুন্দর ফাঁদও। আজ পুরো নাটক দৃশ্য-ধরে ধরে, openssl দিয়ে live খুলব, শেষে certificate-chain-এর নিজস্ব ইন্সপেক্টর বানাব।

মূল ধারণা

কী guarantee, কী নয়

Guaranteeমানেmechanism
Confidentialitytraffic পড়া যায় নাsymmetric AEAD encryption
Integritybytes বদলালে ধরা পড়েAEAD authentication tag
Authenticitycounterpart-এর পরিচয় যাচাইcertificate chain + signature
যা দেয় নাকেন
AnonymityDNS plaintext; SNI field-এ কোন site-এ যাচ্ছেন দৃশ্যমান (ECH চলছে)
AvailabilityDDoS আটকায় না — connection-এর জন্মেরই আগে মার
Endpoint safetydevice malware-infected হলে encryption app-ভেতরেই শেষ

HTTPS = HTTP over TLS over TCP — HTTP-র semantics (methods, status, headers) এক ইঞ্চিও বদলায় না; TLS transport-এ encrypted tunnel বসায়, তার ভেতর HTTP হুবহু চলে। Separation-ই HTTPS migration এত সফল হওয়ার কারণ: application-code change zero।

One round-trip — দুই থেকে এক

TLS 1.2-এর নাটক ছিল দুই flight-এর; 1.3-এর কৌশল: client প্রথম message-এই key-exchange contribution পাঠিয়ে দেয় —

Client                                          Server
  │── ClientHello ────────────────────────────────▶│
  │     supported_versions: TLS 1.3                │
  │     key_share: [X25519 public key]             │
  │     cipher_suites: AES-256-GCM …               │ ECDHE:
  │◀── ServerHello ────────────────────────────────│ (my_priv × your_pub)
  │     key_share: [server's X25519 pub]           │ = shared secret
  │◀═══ {EncryptedExtensions} ═════════════════════│
  │◀═══ {Certificate, CertificateVerify} ══════════│ ← chain+signature
  │◀═══ {Finished} ════════════════════════════════│ ← transcript MAC
  │── {Finished} ─────────────────────────────────▶│
  │═══ Application Data (HTTP!) ══════════════════▶│

{} চিহ্ন = encrypted flight। ServerHello-এর পরে সব encrypted — certificate-সহ! 1.2-তে cert plaintext যেত; observer জানত আপনি কোন site- এর cert দেখছেন। 1.3 সেই window-ও বন্ধ করল।

Shared secret → traffic keys (conceptual pipeline)

client_priv × server_pub  ─┐        elliptic-curve DH — wire থেকে
                           ├──▶    কেউ এটা বের করতে পারে না
server_priv × client_pub  ─┘        = ECDHE shared secret
          │
          ▼ HKDF-Extract (uniform key-material)
   handshake_secret
          │
          ▼ HKDF-Expand chain (transcript-hash মিশিয়ে)
   client/server_handshake_traffic_secret
          │ Finished-এর পরে re-key
          ▼
   client/server_application_traffic_secret  ← আসল HTTP-data keys

তিনটা ধরে রাখুন: (১) ECDHE-র সৌন্দর্য — প্রকাশ্য public-value exchange থেকেও shared-secret (discrete-log infeasibility)। (২) raw DH output key নয় — HKDF extract-expand করে per-direction keys বানায়। (৩) transcript hash = এ-পর্যন্ত সব handshake-message-এর running digest; Finished-এ সেটা verify হয় — middle-tampering-এর cryptographic প্রমাণ।

0-RTT — দ্রুততার দাম

আগের visit-এ server session-ticket (PSK) দিলে, পরের visit-এ:

ClientHello + early_data(HTTP request!), ticket ──▶ server
◀──────────── response সঙ্গে সঙ্গেই ────────────────

Round-trip শূন্য — প্রথম flight-এই HTTP request। দাম: early-data-র freshness guarantee নেই — captured flight হুবহু replay করলে server execute করতে পারে। Rule-of-thumb: 0-RTT-তে idempotent-only (GET, assets); payment POST, login — কখনোই না। Browser-রা default off।

ভেতরে কী ঘটছে

Certificate chain — ভরসা ভাঙা-জোড়া

Server-এর cert নিজে বিশ্বাসযোগ্য নয় — মূল্য chain-এ। OS/browser-এ বসে ~150টা root CA (trust store); verification-পথ:

leaf:  CN=www.example.com            ← server পাঠায়
        ↑ signed by
intermediate: CN=DigiCert ... CA1    ← server পাঠায়
        ↑ signed by
root: CN=DigiCert Global Root        ← পাঠায় না — আপনার store-এই!

Validator নামতে-নামতে signature verify করে: leaf→intermediate-key, intermediate→root-key, root store-এ আছে। Root পাঠানো হয় না কেন? দরকার নেই — পাঠালে attacker-ও নিজের fake-root সাথে পাঠানোর সুযোগ পেত; বিশ্বাসের anchor সবসময় local।

Signature algorithm সাধারণত ECDSA বা RSA — RSA (factoring hardness) আজও root-গুলোর common choice, leaf-cert ECDSA-তে ঝুঁকছে (ছোট key, fast verify)। মনে রাখুন: signing asymmetric, bulk encryption symmetric — TLS-এর দুই হাত দুই কাজে; asymmetric মহঙ্গা বলে শুধু handshake-এ, data চলে AES-GCM-এ।

Cipher suites — তালিকা খর্ব

1.2-এ suite = full recipe: key-exchange+auth+cipher+hash মিলে শতশত combination, অনেকগুলো broken। 1.3 কুঠার মেরেছে: key-exchange/auth protocol-fixed ((EC)DHE+cert সবসময়); suite-এ বাকি শুধু AEAD+hash:

TLS_AES_128_GCM_SHA256        ← mandatory
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256  ← AES-hardware-hীন mobile-এর favorite

Negotiation one-shot, RC4/3DES/CBC-era দুর্ঘটনার door-ই নেই।

Downgrade protection

পুরনো/broken version-এ নামিয়ে-আনার attack আটকাতে দুই mechanism: supported_versions extension — client ঘোষণা করে 1.3 জানে; legacy version-field middlebox-decision আর ভিত্তি হয় না। আর sentinel: 1.3- capable server 1.2-client-এর সাথে 1.2 negotiate করলেও ServerHello.random- এর শেষ ৮ byte magic-marker বসায় — aware-party পরে দেখে downgrade-abort। Finished-এর transcript-MAC মাঝপথ tampering-ও ঢেকে দেয়।

উদাহরণ

একটা সম্পূর্ণ handshake — openssl-এর চোখে

openssl s_client -connect example.com:443 -servername example.com

Output-এর মূল্যবান অংশ annotated:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384       ← negotiated suite
Secure Renegotiation IS NOT supported                ← 1.3-তে renegotiation নেই-ই
---
Certificate chain
 0 s:CN = www.example.com                            ← leaf subject
   i:C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
 1 s:C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
   i:C=US, O=DigiCert Inc, CN=DigiCert Global Root CA
---
Subject: CN = www.example.com      ← host-match এখানেই চোখে যাচাই
Issuer:  ...DigiCert...CA1         ← chain-walk এখান থেকে শুরু
Verify return code: 0 (ok)         ◀── সবচেয়ে গুরুত্বপূর্ণ লাইন

Verify return code: 0 (ok) — openssl নিজে chain walk করে দেখল: signatures verify, root-in-store, hostname match, date valid। এই এক line browser-এর শান্ত padlock-এর command-line প্রতিরূপ।

Timing-hisab: TCP 1 RTT + TLS 1.3 1 RTT + first-request-response 1 RTT = ~3 RTT to first byte; TLS 1.2 হলে 4। 100ms network-এ 300ms vs 400ms — TTFB-র ২৫% সাশ্রয়, শুধু version-change-এ। 0-RTT resume-এ 3→2। এই গণিতই QUIC-lesson-এর engine।

ছবিতে

Trust-এর মানচিত্র — কে কার উপর দাঁড়িয়ে

        ভরসার শৃঙ্খল                           key material-এর প্রবাহ
┌─────────────────────────┐            ┌──────────────────────────────┐
│ Trust Store (local!)    │            │ ECDHE private keys           │
│  ~150 root CA           │◄──anchor── │   (exchange-ই হয় না!)        │
└───────────▲─────────────┘            │        │                     │
            │ signs                    │        ▼ ECDHE              │
┌───────────┴─────────────┐            │   shared secret             │
│ Intermediate CA         │            │        ▼ HKDF-extract       │
│  offline HSM-key,       │            │   handshake_secret          │
│  online signing         │            │        ▼ HKDF-expand        │
└───────────▲─────────────┘            │   traffic secrets (c/s)     │
┌───────────┴─────────────┐            │        ▼                    │
│ Leaf cert (server-এ)    │            │   AES-GCM ciphertext ══wire │
│  SAN: www.example.com   │            │                             │
│  expiry ≤398 days       │            │ Finished = transcript MAC   │
└───────────▲─────────────┘            │   → tampering-প্রমাণ        │
     browser যাচাই করে                  └──────────────────────────────┘

মর্ম: counterpart-এর পরিচয় অবিচ্ছিন্ন signature-শৃঙ্খলে দাঁড়িয়ে, শেষ anchor আপনার machine-এ; আর কথাবার্তা এমন keys-এ আবৃত যা কখনো wire-এ যায়নি। Chain-ভাঙা বা key-fাঁস = প্রতিশ্রুতি শূন্য।

TLS 1.3 connection-এর পূর্ণ স্থাপত্য — বাঁয়ে ভরসার শৃঙ্খল (who vouches for whom), ডানে key-material-এর প্রবাহ (what becomes what)।

নিজে চালিয়ে দেখুন

EXPERIMENT

Live handshake খুলুন — openssl আর curl দিয়ে

macOS / Linux (openssl built-in)· ২০ মিনিট

ধাপ ১ — পূর্ণ handshake আর chain:

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_128_GCM_SHA256
# Peer certificate: CN = www.example.com
# Verification: OK

-showcerts যোগ করলে chain-এর সব cert PEM — example-section-এর annotated output-এর সাথে মিলান।

ধাপ ২ — version enforcement:

openssl s_client -connect example.com:443 -tls1_1 </dev/null 2>&1 | grep -i alert
# sslv3 alert handshake failure   ← fail করাটাই সঠিক behavior
echo | openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | grep 'Protocol'

Major sites 2018-পর TLS 1.0/1.1 off — downgrade-policy-র operational form।

ধাপ ৩ — curl verbose TLS-lines decode:

curl -sv https://example.com -o /dev/null 2>&1 | grep -Ei 'ssl|tls|alpn'
# * ALPN: offers h2,http/1.1     ← TLS-এর ভেতরেই HTTP/2 negotiate!
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
# * ALPN: server accepted h2

ALPN-এর সৌন্দর্য: HTTP-version-ও TLS decide করে — separate round-trip নেই।

ধাপ ৪ — expiry monitor scripting:

for d in github.com wikipedia.org cloudflare.com; do
  exp=$(echo | openssl s_client -connect "$d":443 -servername "$d" 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ( $(date -j -f '%b %d %H:%M:%S %Y %Z' "$exp" +%s) - $(date +%s) ) / 86400 ))
  printf '%-16s expires in %4d days\n' "$d" "$days"
done
# (Linux-এ date -d "$exp" +%s ব্যবহার করুন)
# github.com        expires in   62 days

Production expiry-monitoring ঠিক এভাবেই — threshold-এ alert।

এটা কী প্রমাণ করে

Negotiated version, cipher, পূর্ণ certificate chain, verify result, expiry — TLS-এর internal state standard-tool দিয়েই পড়া যায়; black box নয়।

নিজে বানান

BUILD IT

cert_chain.py — যেকোনো domain-এর certificate tree + expiry alert

Python · ●●●○○
  1. openssl s_client -showcerts চালিয়ে chain-এর সব PEM সংগ্রহ
  2. প্রতিটায় openssl x509 চালিয়ে subject/issuer/dates/SAN বের করুন
  3. Leaf→root গাছ প্রিন্ট — who-signs-whom চোখে
  4. notAfter parse করে today-তুলনা — threshold-এ WARNING
  5. Hostname-SAN match নিজে যাচাই (wildcard logic সহ)

openssl subprocess-এ — crypto-library dependency নেই:

#!/usr/bin/env python3
"""cert_chain.py DOMAIN [WARN_DAYS] — chain tree + expiry + SAN check"""
import datetime, re, subprocess, sys


def pem_certs(host, port=443):
    out = subprocess.run(
        ['openssl', 's_client', '-connect', f'{host}:{port}',
         '-servername', host, '-showcerts'],
        input='', capture_output=True, text=True, timeout=15).stdout
    return re.findall(r'-----BEGIN CERTIFICATE-----.*?'
                      r'-----END CERTIFICATE-----', out, re.S)


def describe(pem):
    out = subprocess.run(
        ['openssl', 'x509', '-noout', '-subject', '-issuer',
         '-startdate', '-enddate', '-ext', 'subjectAltName'],
        input=pem + '\n', capture_output=True, text=True).stdout
    d = {}
    for line in out.strip().splitlines():
        if '=' in line:
            k, _, v = line.partition('=')
            d[k.split()[-1]] = v.strip()
    d['sans'] = [s[4:] for s in re.findall(r'DNS:[^,\s]+', out)]
    return d


def days_left(not_after):
    dt = datetime.datetime.strptime(not_after, '%b %d %H:%M:%S %Y %Z')
    return (dt.replace(tzinfo=datetime.timezone.utc)
            - datetime.datetime.now(datetime.timezone.utc)).days


def matches(host, sans):
    for san in sans:
        if san.startswith('*.') and host.endswith(san[1:]) \
                and host.count('.') > san.count('.'):
            return True
        if san == host:
            return True
    return False


host = sys.argv[1] if len(sys.argv) > 1 else 'example.com'
warn = int(sys.argv[2]) if len(sys.argv) > 2 else 30
certs = pem_certs(host)
if not certs:
    sys.exit(f'{host}: handshake/certificate পাওয়া যায়নি')

names = ['LEAF'] + [f'intermediate {i}' for i in range(1, len(certs))] \
        + ['ROOT']
print(f'{host}-এর chain ({len(certs)} certs):\n')
for i, pem in enumerate(certs):
    c = describe(pem)
    left = days_left(c['enddate'])
    flag = 'EXPIRING-SOON!' if left < warn else 'ok'
    print(f'{"    " * i}└─ {names[i]}')
    print(f'{"    " * i}    subject : {c["subject"]}')
    print(f'{"    " * i}    issuer  : {c["issuer"]}')
    if c['sans']:
        print(f'{"    " * i}    SAN     : {", ".join(c["sans"][:6])}')
    print(f'{"    " * i}    expiry  : {c["enddate"]} ({left} দিন) {flag}\n')

leaf = describe(certs[0])
print(f'hostname check : {host} vs SAN → '
      f'{"MATCH" if matches(host, leaf["sans"]) else "MISMATCH"}')
print('root-in-store: s_client-এর Verify return code দেখুন (0 = ok)')

Run:

python3 cert_chain.py github.com 30
# github.com-এর chain (3 certs):
#
# └─ LEAF
#       subject : CN = *.github.com
#       issuer  : CN = Sectigo ECC Domain Validation Secure Server CA
#       SAN     : *.github.com, github.com, *.githubusercontent.com
#       expiry  : Mar 18 23:59:59 2027 GMT (205 দিন) ok
#     └─ intermediate 1 ...
#         └─ ROOT ...
# hostname check : github.com vs SAN → MATCH

নিজে বাড়ান: (১) openssl verify দিয়ে full-chain verification; (২) multi-domain batch mode + monitoring exit-codes; (৩) crt.sh CT-log query — এই domain-এ আর কোন cert issued?

বাস্তব সিস্টেমে

TLS আজ কোথায় কোথায়

Web-এর প্রায় সব। Firefox telemetry: page-load-এর ৯৩%+ HTTPS — 2013-এ ~33%। Let’s Encrypt (2015-) free automated cert-ই flip-এর বড় চালিকা; ACME protocol এখন IETF standard (RFC 8555)।

API-economy। Mobile-app↔backend, IoT↔cloud, webhook↔receiver — সব TLS। App-রা certificate-pinning করে (specific cert-এ আটকে) MITM-app আটকায়।

Post-quantum এখনই। Chrome-traffic-এর বড় অংশ X25519+ML-KEM hybrid key-share — ClientHello key_share array-তে দুই algorithm পাশাপাশি; harvest-now-decrypt-later threat-এর জবাব। Extensible-design-ই migration সম্ভব করল: protocol বদলে না, extension বদলায়।

Failure-stories curriculum। Heartbleed (2014): OpenSSL memory-read bug, cert-key ফাঁস — revocation-ecosystem crisis। DigiNotar (2011): CA compromise, Iran-এ forged gmail-cert — CA-র death-sentence + certificate-transparency log-এর জন্ম (আজ প্রতিটা বৈধ cert public-log-এ বাধ্য; crt.sh দিয়ে যে-কেউ query)। Trust-system-এর governance-ই distributed- systems lesson।

Mixed content বাস্তবে। HTTPS page-এ http:// script load = active mixed content — browser hard-block করে; image = passive — upgrade-attempt। Encrypted-page-এর unencrypted-hole দিয়ে script ঢুকলে পুরো guarantee ভাঙে। Chain ততটুকুই শক্ত, যতটুকু weakest link।

যে ভুলগুলো সবাই করে

“HTTPS মানে সাইট বিশ্বাসযোগ্য — প্রতারণা হবে না।”

Padlock-মানে শুধু: আপনি যে domain-এর সাথে কথা বলছেন ঠিক সেটার সাথেই, encrypted-ভাবে। phishing.example.com-এরও বৈধ cert থাকতে পারে — CA domain-control যাচাই করে, owner-এর সৎপ্রবৃত্তি নয়। EV-cert-এর green company-name era browsers বাদ দিয়েছে — identity-business-verification web-trust problem solve করেনি। Padlock = secure channel; honest-counterpart নয়।

“0-RTT resumption শুধু দ্রুততা — ঝুঁকি নেই।”

Early-data-র built-in দুর্বলতা: replayability — captured 0-RTT flight replay-এ server execute করতে পারে, আর RFC 8446 স্বীকার করে fully-prevent অসম্ভব (single-use ticket-cache দিয়ে কমানো যায়)। Spec নিজেই বলে: early-data idempotent-only। Payment/password-change/delete — কখনোই না। গতি-বনাম- freshness trade-off protocol-এ baked-in।

“Certificate expire মানে renew করলেই হবে — ছোট ব্যাপার।”

Expired cert = পুরো site/API সব-user-এর কাছে hard-down — soft-warning নয়, full interstitial; API-client certificate-error-এ crash। Ericsson (2016)-এর expired-cert incident-এ UK-র লক্ষাধিক subscriber-এর phone-data বন্ধ — cert web-only জিনিস না, telco-signaling-ও TLS-এ। ACME-renewal automation + expiry-monitoring (build-এর logic) এই class-outage-র একমাত্র টেকসই সমাধান।

“VPN আর HTTPS প্রায় এক — VPN থাকলে HTTPS দরকার নেই।”

Scope ভিন্ন। HTTPS secures one application-flow end-to-end (browser→server); VPN secures device-এর সব traffic — কিন্তু শুধু device→VPN-server; সেখান থেকে internet আবার খোলা, VPN-provider ISP-র মতো observer। HTTPS থাকলেও DNS/SNI metadata leak হতে পারে (anonymity-limit মনে আছে?)। Complementary, substitute নয় — banking-site VPN-এ থাকুক-না-থাকুক HTTPS ছাড়া যেতই না।

বুঝেছেন কি না দেখুন

1

Server-cert encrypted flight-এ যায়, তবু observer বেশিরভাগ ক্ষেত্রে বলে দিতে পারে আপনি কোন site-এ যাচ্ছেন। কোন signals?

যুক্তি

তিন leak-path: (১) DNS — resolve plaintext (DoH/DoT ছাড়া); (২) SNI — ClientHello-র server_name extension encrypted-part-এর আগে (ECH encrypt করার চেষ্টা করছে); (৩) destination IP — unique-IP site হলে IP-ই clue (CDN-hosted shared-IP ভালো লুকায়)। Confidentiality = content; metadata আলাদা battlefield।

2

ECDHE: client-public A=aG, server-public B=bG, shared=abG। Attacker A,B দেখল। সে কী compute করতে পারবে না, আর forward-secrecy নামটা কেন মানানসই?

প্রয়োগ

A, B, G থেকে abG-এর জন্য a (বা b) লাগবে = elliptic-curve discrete-log — infeasible। Forward-secrecy: a,b ephemeral, handshake-শেষে মুছে-ফেলা; server long-term-key পরে চুরি হলেও past-session decrypt না — session-keys-এর জন্ম dead-ephemeral-values থেকে, static-key থেকে নয় (static-RSA key-transport era-র fatal-flaw — Heartbleed-এ practical প্রমাণ; 1.3-তে বাদ-ই)।

3

Intermediate CA কেন daily-signing offline-root নয় — মাঝে ধাপ যোগ করে complexity কেন বাড়াল?

যুক্তি

Risk-isolation। Root-key offline-HSM air-gapped — compromise প্রায় অসম্ভব, কিন্তু daily-mass-signing অসম্ভব। Intermediate online — ভাঙার সম্ভাবনা বেশি, কিন্তু ভাঙলে শুধু ওটা revoke + new-issue; root নিরাপদ, trust-store-update লাগে না। Blast-radius কমানোর classic architecture: high-value-secret exposure যত কম, failure-domain তত ছোট — intermediate =root-এর insurance।

4

Mobile-app-এ login-request 0-RTT early-data-তে পাঠানোর proposal — latency-win দেখানো হচ্ছে। Review-position কী? Latency win আংশিক রেখে replay-free alternative দিন।

ডিজাইন

Reject-for-login। Login non-idempotent-প্রায় (token-issue, rate-limit, audit) — replayed capture = duplicate-login attempts/lockouts/noise। Alternatives: (১) app-start-এ connection pre-warm — login-এর সময় handshake done, same perceived-latency, zero-replay; (২) 0-RTT only config/static-fetch-এ enable, sensitive-endpoint server-side early_data-reject; (৩) PSK-resumption without 0-RTT — 1-RTT থাকে, CPU কমে। Rule: freshness- guarantee বিক্রি হবে না replay-intolerant-কিছুর জন্য।

5

TLS-এর তিন guarantee আর প্রতিটার mechanism — এক লাইনে।

স্মরণ

Confidentiality — symmetric AEAD (AES-GCM); Integrity — AEAD tag + Finished transcript-MAC; Authenticity — cert-chain signature-verification

  • hostname/SAN-check against trust-store। Anonymity/availability এই তিনে নেই।

এরপর কী

এরপর কী

Connection নিরাপদ — কিন্তু ভেতরের HTTP-র খরচ-হিসাব বাকি: HTTP/1.1-এর head-of-line blocking six-connections hack কেন জন্ম দিল, HTTP/2 binary-framing কীভাবে multiplexing আনল, তবু TCP-র নিচে HOL কেন রইল — পরের লেসনে curl হাতে দুই version পাশাপাশি মেপে দেখব।

আরও পড়ুন

  • RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — E. Rescorla · Handshake state machine, key schedule, 0-RTT replay rules — এই লেসনের মূল specification
  • RFC 5280 — Internet X.509 PKI Certificate and CRL Profile — D. Cooper et al. · Certificate structure, SAN, validity period, chain validation-এর আনুষ্ঠানিক সংজ্ঞা
  • RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF) — H. Krawczyk, P. Eronen · Shared secret থেকে traffic key তৈরির extract-expand design