SSL/TLS 如何工作：TLS 握手詳解

2026-05-07

tlshandshakeencryptionsslprotocol

每次你訪問 HTTPS 網站時，瀏覽器和伺服器都會執行一次 TLS 握手——一次快速交換，用於驗證伺服器身份、協商加密引數，並派生共享金鑰。這在任何頁面內容載入之前，透過 1-2 次網路往返（50-200ms）完成。

TLS 1.3 握手（當前標準）

TLS 1.3 在單次往返（1-RTT）中完成握手：

步驟 1 —— Client Hello 瀏覽器傳送：支援的 TLS 版本、支援的密碼套件、隨機數和金鑰共享引數（用於 Diffie-Hellman 金鑰交換）。

步驟 2 —— Server Hello + Certificate + Finished 伺服器響應：選定的密碼套件、其證書（證明身份）、金鑰共享，以及 “Finished” 訊息。在 TLS 1.3 中，證書是加密的——被動觀察者無法看到你連線的是哪個站點。

步驟 3 —— Client Finished 瀏覽器根據其可信 CA 列表驗證證書，從 Diffie-Hellman 交換中計算共享會話金鑰，併傳送 “Finished” 訊息。加密的應用資料現在可以傳輸了。

總計：1 次往返。 恢復的連線（用戶端之前連線過）可以使用 0-RTT——在第一條訊息中就傳送加密資料。

TLS 1.2 握手（仍被廣泛使用）

TLS 1.2 需要 2 次往返：

Client Hello → 支援的版本、密碼套件、隨機數
Server Hello → 選定的密碼套件、證書、伺服器金鑰交換
Client Key Exchange → 預主金鑰（用伺服器公鑰加密或透過 Diffie-Hellman）
Change Cipher Spec + Finished（雙方）

TLS 1.2 支援更多密碼套件——包括一些弱的。正確配置比 TLS 1.3 更重要。

加密連線內部發生了什麼

握手完成後，所有資料使用協商的會話金鑰進行加密，採用對稱加密演算法（通常是 AES-256-GCM 或 ChaCha20-Poly1305）：

機密性 —— 資料被加密；只有兩端能讀取
完整性 —— 每條訊息包含 MAC（訊息認證碼）；任何篡改都會被檢測到
認證 —— 伺服器的證書證明其身份（可選地，用戶端也是）

每個 HTTP 請求和響應——頭部、正文、Cookie、URL——都透過這條加密通道傳輸。

前向保密

現代 TLS 使用臨時 Diffie-Hellman 金鑰交換，意味著每個連線生成唯一的會話金鑰。即使伺服器的私鑰後來被洩露，過去的對話也無法被解密。

TLS 1.3 使前向保密成為強制性的。TLS 1.2 支援它但也允許 RSA 金鑰交換（不提供前向保密）。這就是為什麼推薦 TLS 1.3。

證書的作用

TLS 握手依賴於伺服器擁有有效的 SSL/TLS 證書。證書提供：

伺服器的公鑰 —— 在金鑰交換中使用
域名 —— 瀏覽器檢查它們是否與 URL 匹配
CA 簽名 —— 證明受信任的憑證授權機構為此證書背書
有效期 —— 瀏覽器拒絕過期證書

沒有有效證書，握手失敗，瀏覽器顯示安全警告。獲取免費證書 →

效能

	TLS 1.2	TLS 1.3
完整握手	2 次往返	1 次往返
恢復會話	1 次往返	0-RTT（第一條訊息即傳送資料）
增加的延遲	20-80ms	10-40ms
密碼套件協商	複雜（37 個密碼套件）	簡單（5 個密碼套件）

在現代硬體上，加密的 CPU 開銷可以忽略——AES-NI 指令在硬體中處理。主要成本是額外的往返，TLS 1.3 將其最小化。

在網路上能看到什麼

不使用 HTTPS（HTTP）

網路觀察者可以看到一切：

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

使用者名稱、密碼、Cookie、頁面內容——全部明文。

使用 HTTPS（TLS）

同一個觀察者看到：

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

他們可以看到目標 IP 地址和 SNI 主機名（在 TLS 1.2 中——TLS 1.3 中使用 ECH 加密）。他們無法看到 URL 路徑、頭部、正文或 Cookie。

證書如何參與

TLS 握手依賴於伺服器擁有有效的 SSL/TLS 證書：

伺服器的公鑰 —— 在金鑰交換中使用
域名 —— 瀏覽器檢查它們是否與 URL 匹配
CA 簽名 —— 證明受信任的憑證授權機構為此證書背書
有效期 —— 瀏覽器拒絕過期證書

沒有有效證書，握手失敗，瀏覽器顯示安全警告。獲取免費證書 →

2026 年常見的 TLS 密碼套件

TLS 1.3（僅 5 個密碼套件——全部安全）

TLS_AES_256_GCM_SHA384       ← Most common
TLS_AES_128_GCM_SHA256       ← Widely used
TLS_CHACHA20_POLY1305_SHA256 ← Best for mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2（僅使用 AEAD 套件）

ECDHE-ECDSA-AES256-GCM-SHA384  ← Best with ECC cert
ECDHE-RSA-AES256-GCM-SHA384    ← Best with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305  ← Mobile-optimized

避免 TLS 1.2 中的非 AEAD 套件（CBC 模式）——它們已被 BEAST 和 Lucky13 等攻擊證明存在漏洞。