案例研究：傳輸層安全性（TLS）#

讓我們把協定安全與密碼學的理論套用到一個真實協定上。傳輸層安全性（Transport Layer Security, TLS）（前身為 Secure Sockets Layer, SSL）是網際網路上最常見的安全協定。它由 Netscape 於 1990 年代中期以 SSL 之名開發，用於保護 HTTP 連線，歷經 SSL 1.0 ～ 3.0 與 TLS 1.0 ～ 1.2 多次改版。雖然最初為 HTTP 設計，TLS 可用於任何 TCP 協定，甚至有給 UDP 等不可靠協定使用的變體 DTLS。

TLS 運用了本章描述的許多構造：對稱與非對稱加密、MAC、安全金鑰交換與 PKI。以下討論以 TLS 1.0 為主（當時最普遍支援的版本），但要留意 1.1 與 1.2 因 1.0 的安全問題正逐漸普及。

TLS 交握（The TLS Handshake）#

建立新 TLS 連線最重要的部分是交握（handshake）：用戶端與伺服器在此協商加密方式、交換這次連線專屬的金鑰、並驗證彼此身分。所有通訊都透過 TLS Record 協定——一種預先定義的標籤-長度-值（tag-length-value）結構，讓解析器能從位元組流中擷取個別紀錄。所有交握封包的標籤值都是 22，以與其他封包區隔。

交握資料來回傳送，過程可能很耗時。它有時可被截短或完全略過：用戶端可提供唯一的工作階段識別碼，要求伺服器恢復先前的工作階段（session resumption）、沿用先前協商的金鑰。這不是安全問題——惡意用戶端雖能請求恢復，卻仍不知道那把私密的協商工作階段金鑰。

初始協商（Initial Negotiation）#

交握第一步，用戶端與伺服器以 HELLO 訊息協商連線的安全參數：

• 用戶端 HELLO 含一個用戶端隨機值（client random），確保連線過程不易被重放（replay），並列出用戶端支援的密碼種類。
• TLS 雖對加密演算法設計得很有彈性，但只支援對稱式密碼（如 RC4 或 AES），因為公開金鑰加密的運算成本太高。
• 伺服器以自己的 HELLO 回應，指出它從用戶端清單中選定的密碼（若雙方無法協商出共同密碼，連線就結束），並附上伺服器隨機值（server random）增加重放保護。
• 接著伺服器送出自己的 X.509 憑證及任何必要的中繼 CA 憑證，最後送出 HELLO Done 通知用戶端可進入驗證階段。

端點身分驗證（Endpoint Authentication）#

用戶端必須確認伺服器憑證合法且符合自身安全要求：

• 驗證身分：把憑證 Subject 欄位與伺服器網域名稱比對。Subject 是個 X.500 名稱，含 Organization、Email 等欄位，但交握時只檢查其中的通用名稱（Common Name, CN）。CN 可用萬用字元，例如 *.domain.com 可同時匹配 www.domain.com 與 blog.domain.com。

  

• 驗證信任：建立該憑證與中繼 CA 憑證的信任鏈，確認鏈中沒有任何憑證出現在憑證撤銷清單上。若鏈的根不受用戶端信任，就可判定憑證可疑並中斷連線。

  

TLS 也支援選用的用戶端憑證，讓伺服器反向驗證用戶端。若伺服器在 HELLO 階段送出可接受的根憑證清單，用戶端便挑選最合適的憑證回送，並附上一則「涵蓋至此所有交握訊息雜湊」、以憑證私鑰簽署的驗證訊息。伺服器驗證簽章與憑證中的金鑰相符即可授權存取。這個簽章向伺服器證明用戶端確實持有憑證對應的私鑰。

建立加密（Establishing Encryption）#

端點通過驗證後，用戶端與伺服器即可建立加密連線：

1. 用戶端產生一個隨機的前主密鑰（pre-master secret），用伺服器憑證的公鑰加密後送出。
2. 雙方各自把前主密鑰與用戶端、伺服器隨機值結合，用來作為亂數產生器的種子，產生 48 位元組的主密鑰（master secret），即這次加密連線的工作階段金鑰。
3. 用戶端送出 change cipher spec 封包，宣告自此只送加密訊息。
4. 用戶端再送出 finished 封包：以工作階段金鑰加密，內含至此所有交握訊息的雜湊。伺服器收到後可驗證協商的金鑰正確（否則解不開）並核對雜湊；正確則回送自己的 change cipher spec，加密通訊正式開始。

finished 封包中的交握雜湊是防範降級攻擊（downgrade attack）的關鍵一步：攻擊者若試圖竄改交握、逼雙方選用較弱的加密演算法，最終的雜湊核對就會失敗。此外，每個加密封包都以 HMAC 驗證，提供資料鑑別與完整性——當協商出的是 RC4 這類串流加密法時尤其重要，否則加密區塊可被輕易竄改。

滿足安全要求（Meeting Security Requirements）#

TLS 成功滿足了本章開頭列出的四項安全要求：

TLS 最重大的問題是它完全仰賴以憑證為基礎的 PKI。協定假設憑證都簽發給了正確的人與組織——但企業與政府顛覆 CA 流程簽發憑證的案例已有記載，CA 未盡查核之責誤發憑證（如一度必須撤銷的 Google 憑證）也曾發生。

針對憑證模型的部分修補是憑證釘選（certificate pinning）：應用限制特定網域可接受的憑證與 CA 簽發者。即使有人為 www.google.com 詐得一份有效憑證，應用也會發現它不符 CA 限制而中斷連線。

釘選並非萬用。最主要的難題是釘選清單的維護：建立初始清單或許不難，更新卻是額外負擔；開發者也無法輕易把憑證遷移到另一個 CA、或在不對所有用戶端發送更新的情況下更換憑證。

TLS 另一個面對網路監控的問題是：攻擊者可先擷取並保存 TLS 連線，日後若取得伺服器私鑰，所有歷史流量都能被解密。為此，愈來愈多應用改用 DH 演算法交換金鑰、同時仍以憑證驗證身分，以達成完全前向保密（perfect forward secrecy）——即使私鑰外洩，也不易反算出 DH 產生的金鑰。

結語#

本章聚焦於協定安全的基礎。協定安全牽涉層面眾多、極為複雜，因此在任何協定分析中，理解「哪裡可能出錯」並及時辨識問題至關重要。

• 加密把明文轉成密文，讓攻擊者難以擷取網路上傳送的敏感資訊。
• 簽章用來驗證傳輸的資料未遭破壞，適當的簽章還能驗證發送者身分，這對在不受信任的網路上鑑別使用者與電腦非常有用。
• 本章也描述了數種針對密碼學的攻擊，包括著名的填充預言攻擊，它可能讓攻擊者解密進出伺服器的流量。後續章節將更深入說明如何分析協定的安全組態，以及保護敏感資料所用的加密演算法。