一、HTTP vs HTTPS 概覽

HTTPS = HTTP + 加密認證（基於 TLS），能防止被中間人竊聽與篡改，並證明服務器身份。

  • 非對稱（RSA/ECDSA）用於​做身份認證與安全協商密鑰​（但慢）。
  • 對稱加密速度快，適合實際數據傳輸。
  • 握手用非對稱協商對稱會話密鑰，然後用對稱加密通信。

二、SSL/TLS 握手

先看 ​傳統 TLS1.2（常見）握手流程​：

  1. ClientHello

    1. 支持的協議版本（TLS1.2）、隨機數（ClientRandom）等

  2. ServerHello

    1. 選擇協議版本、ServerRandom、返回服務器證書（Certificate）等

  3. Certificate

    1. 服務器發送證書鏈（證書由 CA 簽名，確保不會被第三方冒充）
    • 證書（X.509）包含服務器​公鑰​、頒發者、有效期、域名（SAN）等，並由 ​CA（證書頒發機構）簽名​。
    • 瀏覽器維護信任根證書列表（根 CA）。驗證過程：證書鏈驗證（瀏覽器/系統根證書-> 中間證書-> 服務器證書） → 簽名校驗 → 主機名匹配 → 未過期 → 未吊銷。

  4. ServerKeyExchange（可選）

    1. 如果使用 DHE/ECDHE，會發送參數（橢圓曲線簽名(非對稱算法)、公鑰）以支持臨時公鑰

    沒有 PFS，如果服務器私鑰泄露，攻擊者可以解密​所有歷史抓到的 TLS 流量​。

    RSA/DHE/ECDHE 都是密鑰交換算法。

    證書中公鑰    → 用來證明：你是淘寶/微博/銀行
臨時密鑰對    → 用來協商：本次會話的對稱加密 key

  5. ServerHelloDone

  6. ClientKeyExchange

    1. 若用 ​**RSA key-exchange（老）**​：客户端生成 pre-master secret 預主密鑰，用服務端公鑰加密發送；
    2. 若用 ​**(EC)DHE（推薦）**​：客户端與服務端各自生成臨時密鑰對並互換公鑰，雙方基於 DH 算法計算相同的 pre-master secret（實現 PFS）。
    3. 所以密鑰的生成和交換使用非對稱加密。

  7. 雙方計算對稱會話密鑰

    1. 基於 ClientRandom、ServerRandom、pre-master secret 派生出 symmetric keys（session key）

  8. ​ChangeCipherSpec + Finished​（客户端/服務端互換）

    1. 表示接下來使用協商好的加密算法並驗證握手完整性
    2. 通信數據使用“密鑰 session key”進行對稱加密

TLS1.3（更簡化、更安全、更快）：

  • ​握手輪次更少​（1-RTT）：ClientHello → ServerHello(+Certificate) → Finished（部分情形）

    RTT = 請求發出 → 到服務器 → 再返回響應 的總耗時

  • ​移除不安全算法​（RSA key-exchange 被棄用，默認用 ECDHE）
  • 默認啓用前向保密（PFS）

    PFS（DHE/ECDHE）：握手階段生成臨時密鑰對，協商一次性 session key，只存在於本次會話。所以，後面即使私鑰泄露，也無法解密過去已經發生的 HTTPS 會話內容。

  • ​**支持 0-RTT（復會話可達零往返延遲）**​：適用於會話恢復，但需注意重放攻擊風險

三、單次請求響應的加密與解密（在 TLS 隧道內）

  • ​客户端準備應用層數據​（例如 JSON 表單或請求體）。
  • ​**加密（記錄層）**​：TLS Record Layer 將應用數據分片並使用協商好的對稱算法（如 AES-GCM）進行加密並附帶認證（AEAD 同時提供完整性與防篡改），生成密文包。
  • ​傳輸​：密文經 TCP（或 QUIC/UDP）發送到服務器。中間節點只能看到包頭和元信息（如 IP、端口、SNI 在 ClientHello），但看不到加密的 HTTP 頭體。
  • ​服務端解密​：服務端用對應的 session key 解密記錄層數據，驗證完整性（AEAD tag），還原出應用層的請求（如 HTTP headers + body）。
  • ​服務端處理並響應​：服務端處理請求，生成響應體；響應同樣被 TLS 記錄層用對稱密鑰加密併發回客户端。
  • ​客户端解密並使用數據​：客户端解密響應並把明文交給瀏覽器/應用進行渲染或後續處理。

四、HTTP 安全問題

HTTP 是明文傳輸的協議，任何能看到你和服務器之間網絡流量的中間節點，都能 ​讀到（竊聽）或修改（篡改）​請求/響應內容。中間人攻擊（MITM）就是利用這點，在通信雙方之間插入自己，從而竊聽或篡改通信。

為什麼 HTTP 會被竊聽或篡改？

  1. HTTP 是明文傳輸
    1. 瀏覽器發出的請求（包括 Headers、Cookie、請求體）在網絡上以未加密的數據包形式傳輸，任何能捕獲這些包的人都能直接看到內容（用户名、密碼、session cookie、POST 的 JSON 等）。
    2. 舉例：POST /login 的 body username=xxx&password=yyy 直接可見。
  2. 網絡是分段、多設備中轉的
    1. 一次 HTTP 請求從客户端到服務器，會經過本地路由器、運營商、骨幹網、目標網段等多個設備；這些設備中的任何一個若被監聽或被配置（如 ISP 的透明代理）都能截獲或修改流量。
  3. 很多鏈路不受信任（公共 Wi-Fi）
    1. 公共 Wi-Fi、酒店網絡、機場網絡等通常不加密或由第三方管理，攻擊者可以很容易地在同一網絡內捕獲流量或者搭建釣魚熱點。
  4. 網絡地址映射與中間路由的脆弱性
    1. ARP、DNS、路由協議等都有被篡改的可能（ARP 欺騙、DNS 緩存投毒），攻擊者可以把流量導向自己機器然後再轉發到真實服務器（對用户透明）。

什麼是中間人攻擊（MITM）

​定義​：攻擊者在客户端與服務器之間插入自己，使得雙方都以為在直接通信，但實際通信被攻擊者觀測、記錄、修改或偽造響應。

​**分類（按行為）**​：

  • ​被動竊聽​（Eavesdropping） 只監聽並記錄流量，不改動（例：抓包收集賬號密碼）。
  • 主動篡改 / 攔截並修改在流量中注入、替換或刪除內容（例：把 JS 替換為惡意腳本、在頁面注入釣魚表單）。
  • 重放攻擊攻擊者記錄某個合法請求後重新發送（例如重複交易），如果服務器不防重放會被利用。
  • **中轉代理 / 透明代理（ISP 層）**ISP 或網絡設備以透明方式攔截並可能修改請求（插入廣告、注入 JS、替換資源）。

常見的 MITM 實現手段

  1. ARP 欺騙 / ARP Spoofing（局域網）
    1. 攻擊者在局域網發送偽造 ARP，欺騙局內主機把網關 MAC 路由指向攻擊者機器。流量經過攻擊者後再轉發到網關 → 攻擊者可截獲/修改。
  2. DNS 緩存投毒 / DNS 劫持
    1. 攻擊者讓用户解析域名到惡意 IP（偽造解析結果），用户訪問的是攻擊者服務器（或代理），從而被監聽或被劫持到釣魚頁面。
  3. 流量劫持 / 路由劫持（BGP Hijack）
    1. 在互聯網核心路由被操控時，流量被引導到惡意自治系統，可能被截獲/分析（多見於高級攻擊或誤配置）。
  4. 惡意 Wi-Fi 熱點 / Evil Twin
    1. 攻擊者開一個與合法熱點很像的熱點，用户連上後所有流量通過攻擊者機器。
  5. 透明代理 / 企業中間件
    1. 企業或 ISP 部署中間代理，可能會解密/重寫流量（在某些企業這是被允許的；但若被濫用就是 MITM）。
  6. ​證書欺騙 / 惡意 CA / 偽造證書​（針對 HTTPS 的 MITM）
    1. 攻擊者利用被入侵或惡意 CA 簽發假的證書，或在客户端植入自簽證書，從而對 HTTPS 做中間解密（更為高級且危險）。

五、證書的獲取

服務器證書就是 ​HTTPS 用的 TLS/SSL 證書​，用來證明：

訪問 https://www.example.com 時，這個服務器確實是 example.com 的官方服務器。

證書由 CA（證書頒發機構） 頒發，要滿足以下兩點：

  1. 客户端（瀏覽器）能驗證證書是否被權威 CA 信任。
  2. 證書包含域名信息（example.com），確保不會被第三方冒充。

獲取服務器證書的常見方式：