TLS 1.3 是傳輸層安全協議的當前版本，於 2018 年 8 月釋出為 RFC 8446。它是一次根本性的重新設計——不是增量更新——使 HTTPS 更快、更簡單、更安全。
截至 2026 年，62% 的網站支援 TLS 1.3，所有主流瀏覽器自 2018 年起已支援。
相比 TLS 1.2 的變化
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| 握手 | 2 次往返 | 1 次往返（1-RTT） |
| 恢復連線 | 1 次往返 | 0-RTT（第一條訊息即傳送資料） |
| 密碼套件 | 37 個（許多是弱的） | 5 個（全部安全） |
| 前向保密 | 可選 | 強制 |
| RSA 金鑰交換 | 支援 | 移除 |
| 靜態 DH | 支援 | 移除 |
| CBC 密碼 | 支援 | 移除 |
| RC4、DES、3DES | 部分配置 | 移除 |
| 握手中的 MD5、SHA-1 | 允許 | 移除 |
| 握手中的證書 | 明文（可見） | 加密 |
| 壓縮 | 可選 | 移除（防止 CRIME） |
| 重新協商 | 支援 | 移除 |
設計哲學：移除所有可能被錯誤配置的東西。TLS 1.2 有 37 個密碼套件——有些安全，有些已破解。TLS 1.3 只有 5 個，全部安全。
TLS 1.3 的 5 個密碼套件
TLS_AES_256_GCM_SHA384 ← Strongest, most common
TLS_AES_128_GCM_SHA256 ← Widely used, slightly faster
TLS_CHACHA20_POLY1305_SHA256 ← Best for ARM/mobile (no AES-NI)
TLS_AES_128_CCM_SHA256 ← IoT/embedded
TLS_AES_128_CCM_8_SHA256 ← IoT/embedded (short tag)你無法錯誤配置這些——它們都是帶有強金鑰的 AEAD 密碼。沒有像 TLS 1.2 那樣”意外啟用弱密碼”的風險。
1-RTT 握手：為什麼更快
TLS 1.2 握手（2 次往返）：
Client → Server: ClientHello (supported ciphers)
Server → Client: ServerHello, Certificate, KeyExchange
Client → Server: KeyExchange, ChangeCipherSpec, Finished
Server → Client: ChangeCipherSpec, Finished
[4 messages before encrypted data flows]TLS 1.3 握手（1 次往返）：
Client → Server: ClientHello + KeyShare
Server → Client: ServerHello + KeyShare + Certificate + Finished
Client → Server: Finished
[encrypted data can flow after 1 round trip]用戶端在第一條訊息中就傳送金鑰共享引數——無需等待伺服器先指定演算法。這將握手從 2 次往返縮減為 1 次。
0-RTT 恢復
對於回訪者（之前連線過），TLS 1.3 支援 0-RTT——在第一條訊息中就傳送加密的應用資料：
Client → Server: ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client: ServerHello + response請求在握手完成前就發出。折衷：0-RTT 資料容易受到重放攻擊，因此應僅用於冪等請求（GET，而非 POST）。
強制前向保密
在 TLS 1.2 中，可以使用 RSA 金鑰交換——伺服器的長期 RSA 金鑰直接解密預主金鑰。如果有人記錄流量並稍後竊取伺服器的私鑰，他們可以解密所有過去的對話。
TLS 1.3 完全移除了 RSA 金鑰交換。所有金鑰交換使用臨時 Diffie-Hellman（ECDHE）——每個連線生成唯一的金鑰對。竊取伺服器的私鑰無助於解密過去的會話。更多關於前向保密 →
加密的證書
在 TLS 1.2 中，伺服器的證書（包括域名）在握手時以明文傳送。被動觀察者可以看到你連線的是哪個站點。
在 TLS 1.3 中，證書在握手金鑰派生之後傳送——它是加密的。SNI（Server Name Indication）在 TLS 1.3 中仍然可見，但 Encrypted Client Hello（ECH） 未來也會將其加密。
如何啟用 TLS 1.3
檢查是否已啟用
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Expected: TLSv1.3Nginx（1.13+ 配合 OpenSSL 1.1.1+）
ssl_protocols TLSv1.2 TLSv1.3;TLS 1.3 在現代 Nginx 中預設啟用——你只需不禁用它。
Apache（2.4.37+ 配合 OpenSSL 1.1.1+）
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1這啟用 TLS 1.2 和 1.3。
檢查你的 OpenSSL 版本
openssl version
# Needs: OpenSSL 1.1.1+ for TLS 1.3 support如果你的 OpenSSL 較舊，升級它或升級作業系統。
應該只強制 TLS 1.3 嗎？
目前不建議。 約 38% 的站點不支援 TLS 1.3，一些用戶端（企業代理、Java 8、舊嵌入式系統）只支援 TLS 1.2。今天放棄 TLS 1.2 會鎖定一些使用者。
推薦配置： 同時支援 TLS 1.2 和 1.3。這為現代用戶端提供 TLS 1.3 速度，同時保持相容性。Google、Cloudflare 和大多數主要站點都是這麼做的。
常見問題
TLS 1.3 需要新證書嗎？
不需要。同一張證書適用於 TLS 1.2 和 1.3。證書與協議無關——它們包含公鑰和 CA 簽名，不管哪個 TLS 版本使用它們。
TLS 1.3 影響效能嗎？
是的，正面影響。1-RTT 握手在首次連線時節省 50-100ms。0-RTT 恢復完全消除回訪者的握手延遲。結合 HTTP/2（需要 HTTPS），TLS 1.3 站點明顯更快。
TLS 1.2 還安全嗎？
使用 AEAD 密碼套件（AES-GCM、ChaCha20-Poly1305）和 ECDHE 金鑰交換時是安全的。避免 TLS 1.2 中的 CBC 密碼——它們有漏洞（BEAST、Lucky13）。TLS 1.3 更好，但使用現代密碼的 TLS 1.2 仍然安全。
有 TLS 1.4 計劃嗎？
沒有 TLS 1.4 的計劃。IETF 將 TLS 1.3 視為可預見未來的目標。下一個重大變化將是納入後量子金鑰交換（ML-KEM）作為與現有 ECDHE 的混合方案——這將在 TLS 1.3 內發生，不會作為新版本。