HTTPS 與 TLS 的真正運作方式：握手過程詳解

你輸入一個網址，按下 Enter，然後出現一個鎖頭圖示。但你的瀏覽器與伺服器之間究竟發生了什麼，才讓這個連線變得安全？許多開發者把 HTTPS 當成一個黑盒子——直到出了問題，例如憑證錯誤或效能問題。本文將揭開 TLS（HTTPS 背後的協定）的神祕面紗，並用淺顯易懂的方式解釋握手過程。

HTTPS 到底是什麼

HTTPS 其實就是將 HTTP layered 在 TLS（Transport Layer Security，傳輸層安全性）之上。TLS 提供三項保證：

• 機密性 – 資料經過加密，竊聽者無法讀取。
• 完整性 – 資料在傳輸過程中若被竄改，可以被偵測出來。
• 認證 – 你正在與真正的伺服器通訊，而非冒充者。

沒有 TLS 的話，HTTP 會以明文傳送所有內容：密碼、cookie 和表單資料都會被網路路徑上的任何人看到。

用白話解釋 TLS 握手

握手是在傳送任何應用程式資料之前進行的協商。其目標是：議定加密演算法、驗證伺服器身分，並建立共享的密鑰。以下是現代標準 TLS 1.3 的流程：

1. Client Hello – 瀏覽器傳送支援的加密套件清單、一個隨機值，以及其金鑰共享（用於金鑰交換）。
2. Server Hello – 伺服器選擇一個加密套件，傳送自己的隨機值和金鑰共享，並提供其憑證鏈。
3. 憑證驗證 – 瀏覽器根據受信任的根 CA 檢查憑證、驗證網域名稱，並檢查有效期限。
4. 金鑰衍生 – 雙方使用金鑰交換（通常是 ECDHE）計算出相同的共享密鑰。工作階段金鑰於焉衍生。
5. Finished – 雙方對握手過程的 transcript 傳送 MAC，以確認沒有任何內容遭到竄改。

之後，加密的應用程式資料便開始流動。在 TLS 1.3 中，握手只需一個往返（1-RTT），而重新開始（resumption）可達到 0-RTT。

TLS 1.2 與 TLS 1.3 的比較

TLS 1.2 需要兩個往返，且支援較弱的演算法。TLS 1.3 移除了過時的加密演算法、簡化了握手，並加密更多握手過程本身。請始終優先使用 TLS 1.3；大多數現代伺服器和瀏覽器都支援它。

憑證：信任的錨點

憑證將公開金鑰綁定到網域名稱，並由憑證授權單位（CA）簽署。瀏覽器內建受信任的根 CA 存放區。在驗證期間，瀏覽器會從伺服器的憑證建立一條鏈，向上追溯到受信任的根。

常見的憑證類型：

• DV（網域驗證） – 證明對網域的控制權；快速且免費（例如 Let's Encrypt）。
• OV（組織驗證） – 包含經過驗證的公司詳細資訊。
• EV（延伸驗證） – 更嚴格的身分檢查；在大多數瀏覽器中已不再顯示綠色網址列。

憑證會過期。請使用像 Certbot 這樣的 ACME 用戶端自動續期，以避免服務中斷。

金鑰交換與完美前向保密

現代 TLS 使用臨時金鑰交換（ECDHE）。每個工作階段都會產生新的金鑰對，因此即使伺服器的私密金鑰日後遭到洩露，過去的工作階段也無法被解密。此特性稱為前向保密。請避免使用靜態 RSA 金鑰交換，因為它缺乏此保護。

常見的 HTTPS 陷阱與避免方法

• 混合內容 – 在 HTTPS 頁面上載入 HTTP 資源會觸發瀏覽器警告。請使用相對 URL 或更新為 HTTPS。
• 憑證過期 – 設定監控與自動續期。
• 弱加密套件 – 停用 TLS 1.0/1.1 和 RC4/3DES。使用 SSL Labs 等工具進行測試。
• 缺少 HSTS – 新增 Strict-Transport-Security 標頭以強制使用 HTTPS。

偵錯 TLS 問題

當握手失敗時，使用 openssl s_client 來檢查連線：

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

這會顯示憑證鏈、協商後的協定和加密套件。對於瀏覽器特定的錯誤，請檢查開發人員工具中的「安全性」面板。

常見問題

HTTPS 和 TLS 是一樣的嗎？

HTTPS 是運行在 TLS 上的 HTTP。TLS 是密碼學協定；HTTPS 是 HTTP 應用程式協定的安全版本。

每個子網域都需要单独的憑證嗎？

不一定。萬用字元憑證涵蓋所有第一層子網域，而多網域（SAN）憑證可以列出多個名稱。

TLS 1.3 如何提升效能？

TLS 1.3 將握手減少到一個往返（重新開始時為零），並簡化了加密套件協商，從而降低延遲。

準備好檢查自己網站的安全性了嗎？使用我們的 Nginx 日誌分析器 來找出日誌中可疑的 TLS 錯誤和握手失敗。