HTTPS 與 TLS 究竟如何運作：實用指南
問題：HTTPS 無所不在，但它究竟如何運作？
你在瀏覽器中看到鎖頭圖示，便假設連線是安全的。但當出現問題時——憑證錯誤、混合內容警告，或 TLS 握手緩慢——你需要了解背後發生了什麼。本指南將 HTTPS 和 TLS 分解成實用、易於理解的片段，讓你能夠除錯並優化安全連線。
HTTPS 簡單來說就是將 HTTP 置於 TLS（傳輸層安全性）之上。TLS 提供加密、驗證和完整性。讓我們一步步了解它的運作方式。
TLS 實際的功能
TLS 解決三個核心問題：
- 加密： 防止竊聽者讀取客戶端與伺服器之間交換的資料。
- 驗證： 使用憑證證明伺服器的身分（也可選擇驗證客戶端）。
- 完整性： 確保資料在傳輸過程中未被竄改。
沒有 TLS，HTTP 流量就是純文字——網路路徑上的任何人都可以讀取或修改它。TLS 將 HTTP 包裹在加密隧道中。
TLS 握手：逐步解析
在任何 HTTP 資料流動之前，客戶端和伺服器會執行握手以協商加密參數。以下是 TLS 1.2 的典型流程（TLS 1.3 更快，但概念類似）：
- Client Hello： 客戶端發送支援的 TLS 版本、加密套件和一個隨機值。
- Server Hello： 伺服器選擇 TLS 版本和加密套件，並發送自己的隨機值。
- 憑證： 伺服器發送其憑證鏈，包括公鑰和身分證明。
- 金鑰交換： 使用憑證，客戶端和伺服器透過 ECDHE 等演算法安全地協商出共享密鑰（pre-master secret）。
- 完成： 雙方驗證握手，並切換到使用從共享密鑰衍生的對稱金鑰進行加密通訊。
TLS 1.3 將此簡化為單次往返（1-RTT），甚至支援會話恢復的 0-RTT，使連線更快。
憑證：信任的錨點
憑證將公鑰綁定到一個身分（例如網域名稱）。它由客戶端信任的憑證授權單位（CA）簽署。當你的瀏覽器連線到 https://example.com 時，它會檢查：
- 憑證對該網域有效。
- 由受信任的 CA 簽署。
- 尚未過期。
- 未被撤銷（透過 OCSP 或 CRL）。
如果任何檢查失敗，你會收到警告。在開發環境中，你可以使用自簽憑證，但除非你明確信任它們，否則瀏覽器會標記它們。
常見憑證錯誤與修復方法
| 錯誤 | 可能原因 | 修復方法 |
|---|---|---|
| NET::ERR_CERT_COMMON_NAME_INVALID | 憑證與網域不符 | 使用正確的主體別名（SAN）重新簽發憑證 |
| NET::ERR_CERT_AUTHORITY_INVALID | 自簽或不受信任的 CA | 使用受信任的 CA，或將 CA 安裝到信任存放區 |
| NET::ERR_CERT_DATE_INVALID | 已過期或尚未生效 | 更新憑證並檢查系統時鐘 |
實際加密：對稱與非對稱
TLS 使用兩種加密類型：
- 非對稱（公鑰）加密： 在握手期間用於安全交換共享密鑰。速度慢，但解決了金鑰分配問題。
- 對稱加密： 握手後用於大量資料。AES-GCM 或 ChaCha20-Poly1305 等快速演算法加密實際的 HTTP 流量。
握手產生的共享密鑰用於衍生對稱會話金鑰。這種混合方法同時提供安全性和效能。
除錯 TLS 連線
當 HTTPS 行為異常時，你需要檢查握手過程。以下是一些實用命令和技巧：
1. 使用 OpenSSL 檢查憑證詳細資訊
openssl s_client -connect example.com:443 -servername example.com </dev/null這會印出憑證鏈、加密套件和握手詳細資訊。尋找 Verify return code: 0 (ok) 以確認信任。
2. 測試 TLS 版本和加密套件
nmap --script ssl-enum-ciphers -p 443 example.com這會列出支援的 TLS 版本和加密套件，幫助你識別弱配置。
3. 檢查 HTTP 安全標頭
使用瀏覽器開發者工具（安全性標籤）查看頁面是否完全安全。混合內容（HTTPS 頁面上的 HTTP 資源）會觸發警告，並可能破壞功能。
4. 分析伺服器日誌中的 TLS 錯誤
如果你執行 Nginx，TLS 握手失敗會出現在錯誤日誌中。例如：
2025/01/01 12:00:00 [error] 1234#0: *5 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown) while SSL handshaking, client: 203.0.113.1, server: 0.0.0.0:443這表示客戶端拒絕了憑證。檢查你的憑證鏈和配置。
優化 TLS 效能
TLS 會增加延遲，但你可以將其最小化：
- 啟用 TLS 1.3： 更快的握手和更高的安全性。
- 使用會話恢復： 會話 ID 或票證可減少回訪客戶端的握手開銷。
- 啟用 OCSP 裝訂： 伺服器在握手時包含撤銷狀態，避免客戶端單獨請求。
- 選擇高效的加密套件： 偏好使用硬體加速的 AES-GCM，或在行動裝置上使用 ChaCha20-Poly1305。
- 保持憑證精簡： 最小化鏈長度，並使用 ECDSA 憑證以獲得更小的金鑰。
常見陷阱及避免方法
- 憑證過期： 使用 Let's Encrypt 自動續期並設定監控。
- 不完整的憑證鏈： 始終包含中繼憑證；缺少中繼憑證會在某些客戶端上導致信任錯誤。
- 弱協議： 停用 TLS 1.0 和 1.1；使用 TLS 1.2+ 和強加密套件。
- 混合內容： 確保所有子資源（圖片、指令碼、樣式）都使用 HTTPS。
- HSTS 配置錯誤： 謹慎使用
Strict-Transport-Security標頭；從較短的 max-age 開始。
常見問題
HTTPS 和 TLS 有什麼區別？
HTTPS 是執行在 TLS 上的 HTTP。TLS 是提供加密和驗證的協議。因此，HTTPS 是 HTTP 的安全版本，由 TLS 提供支援。
TLS 1.3 如何改進 TLS 1.2？
TLS 1.3 將握手減少到一次往返（1-RTT），並支援會話恢復的 0-RTT。它還移除了過時和弱的加密演算法，簡化了配置並提高了安全性。
為什麼我在開發環境中會遇到憑證錯誤？
開發伺服器通常使用自簽憑證，瀏覽器預設不信任它們。你可以將憑證新增到信任存放區，或使用 mkcert 等工具產生本機信任的憑證。
需要快速檢查或除錯伺服器日誌中的 TLS 錯誤嗎？試試我們的 Nginx 日誌分析器，在瀏覽器中解析和過濾日誌條目。