HTTPS 如何運作——TLS 握手解說

在一張互動畫布上呈現 HTTPS 如何運作：瀏覽器與伺服器之間的 TLS 握手、憑證頒發機構的角色，以及隨之而來的加密工作階段。

HTTPS 就是在一個加密的工作階段裡運行的 HTTP。在任何一個請求出發之前，瀏覽器與伺服器會先完成一次 TLS 握手——協商、驗證伺服器的憑證，並議定一條只有他們兩方共享的工作階段金鑰。

HTTPS 如何運作——TLS 握手解說

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

  • 先由上而下讀「TLS 握手」這一欄，再讀「安全工作階段」這一欄：先協商，後加密。
  • 「憑證頒發機構」這條泳道並不在訊息的路徑上——它是瀏覽器據以判斷伺服器憑證的那一方，信任由它而來。
  • 「憑證有效且未過期？」這個決策是唯一的分支：憑證有效就繼續走到金鑰交換，無效的則終止於封鎖警告。

握手

「瀏覽器連上 HTTPS 網站」開啟整個流程，而「瀏覽器送出載有支援加密套件的 ClientHello」則宣告瀏覽器可以使用哪些協定版本與加密套件。「伺服器以自己的憑證和一個 ServerHello 回覆」由那些選項中挑一個，並出示自己的身分——一張簽發給該域名的公開金鑰憑證。那張憑證就是 HTTPS 全部信任的錨點。

由誰為伺服器作擔保

「瀏覽器對照 CA 檢查憑證簽章」之所以放在「憑證頒發機構」群組裡，是因為憑證帶有一家 CA 的簽章，而瀏覽器信任該 CA 的公開金鑰。接著「憑證有效且未過期？」這個決策一次過測試三項真正的檢查：簽章、憑證上的域名，以及憑證的有效期與撤銷狀態。「否」分支終止於「瀏覽器封鎖連線並顯示警告」——瀏覽器寧可失敗關閉，也不願載入一個未經驗證的網站。

加密的工作階段

憑證通過信任之後，「瀏覽器用伺服器的公開金鑰加密並送出 pre-master secret」就是那條只有真正的伺服器才解得開的訊息。由它出發，「雙方推導出相同的工作階段金鑰」說明實際的資料根本不是用憑證的金鑰加密的——憑證保護的是金鑰交換，而保護對話的是一條全新的對稱金鑰。「HTTP 訊息以工作階段金鑰加密」與「瀏覽器與伺服器交換加密資料」，就是頁面載入其餘部分裡 HTTPS 的樣子。

Key relationships and takeaways

  • HTTPS = 在加密的 TLS 工作階段上承載的 HTTP；加密發生在任何一條 HTTP 訊息之前。
  • 信任來自憑證頒發機構，而不是來自伺服器：瀏覽器是對照一家它早已信任的 CA 去判斷伺服器的憑證。
  • 憑證的金鑰只用一次，用來保護金鑰交換；實際的資料由一條全新的工作階段金鑰加密。
  • 憑證無效或不受信任就會令連線中止——HTTPS 選擇失敗關閉，而不是把資料未經加密送出。
  • HTTPS 所保護的一切，都跑在互聯網那張圖解所描繪的同一個封包交換網絡之上。

When to use this visual

  • 向團隊解釋那個鎖頭圖示為甚麼會出現，以及一個憑證警告到底代表甚麼。
  • 在工程師著手處理 TLS 問題、過期憑證或混合內容警告之前，先讓他們認識握手。
  • 講解信任模型：CA 的層級結構與憑證驗證如何防止冒充。

運作方式

  1. 寫出你實際的憑證簽發者

    把「憑證頒發機構」群組改名為你的供應商，並在憑證方框上註明憑證類型——DV、OV 還是 EV。

  2. 加入你實際運行的 TLS 版本

    在 ClientHello 那一步標註你真正啟用的協定版本與加密套件，令圖表反映的是你的設定，而不是一份通用的設定。

  3. 把你的失敗分支畫出來

    加入你實際遇過的結果——憑證過期、主機名稱不符、憑證被撤銷——每一條都終止於它所產生的那個明確警告或封鎖。

  4. 把握手拆到你需要的細緻程度

    如果你要講解 TLS 1.3，就把金鑰交換展開成它真實的訊息（Key Share、Finished）；開啟之後，這張畫布就是你的，隨你延伸。

常見問題

HTTP 與 HTTPS 有甚麼分別？

HTTPS 就是在一個加密的 TLS 連線裡運行的 HTTP。請求與回應用的完全是同一套協定；改變的是在任何一條 HTTP 訊息送出之前，瀏覽器與伺服器會先完成一次握手，建立起一個加密的工作階段。傳送的一切——URL、標頭、cookie、回應主體——都只有兩端讀得到。

TLS 握手期間發生了甚麼？

瀏覽器送出一個 ClientHello，列出它支援的協定與加密套件；伺服器回覆它的選擇和自己的憑證；瀏覽器對照一家受信任的憑證頒發機構驗證該憑證；然後雙方交換一個秘密，並由它各自推導出相同的工作階段金鑰。此後 HTTP 訊息就以加密形式流動。圖解把這場交換壓縮成上述四個步驟。

瀏覽器為甚麼需要憑證頒發機構？

因為任何一部伺服器都可以聲稱自己是任何一個域名。憑證頒發機構（CA）就是那個第三方：它先驗證域名確實屬於申請人，才在伺服器的憑證上加上簽章。瀏覽器內建了受信任 CA 的公開金鑰，因此可以自行驗證簽章——正是這一點，把一個自說自話的身分變成一個有人擔保的身分。

憑證警告是甚麼意思？

它代表「憑證有效且未過期？」這個決策裡的其中一項檢查失敗了——憑證已過期、涵蓋的是另一個域名、由一家不受信任的 CA 簽發，或者已被撤銷。瀏覽器選擇封鎖連線而不繼續，因為該網站的身分無法驗證。

用 QueryChart（FlowJam）編輯這張圖解

把上面這張 TLS 握手畫布開啟為你自己的圖表——標註你支援的加密套件，並按你自己的憑證設定調整它。

用 QueryChart（FlowJam）編輯這張圖解

互動圖解的更多內容