【網絡】SSL/TLS介紹

一、SSL/TLS 概述

SSL（Secure Socket Layer） ：最初由網景（Netscape）開發，用于在客戶端和服務器之間建立安全的加密連接，防止數據被竊取或篡改。后來逐步演進，最終被 TLS 取代。
TLS（Transport Layer Security） ： TLS 是 SSL 的后繼協議，目前已經成為互聯網安全通信的標準。它不僅實現了數據加密，還提供了身份驗證和數據完整性保護，確保雙方通信時的信息保密且未被篡改。

在這里插入圖片描述

SSL/TLS協議提供的服務主要有：

認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
加密數據以防止數據中途被竊取；
維護數據的完整性，確保數據在傳輸過程中不被改變。

在這里插入圖片描述

TLS與SSL的差異

版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不同，TLS的版本1.0使用的版本號為SSLv3.1。
報文鑒別碼：SSLv3.0和TLS的MAC算法及MAC計算的范圍不同。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了相似的算法，兩者差別在于SSLv3.0中，填充字節與密鑰之間采用的是連接運算，而HMAC算法采用的是異或運算。但是兩者的安全程度是相同的。
偽隨機函數：TLS使用了稱為PRF的偽隨機函數來將密鑰擴展成數據塊，是更安全的方式。
報警代碼：TLS支持幾乎所有的SSLv3.0報警代碼，而且TLS還補充定義了很多報警代碼，如解密失敗（decryption_failed）、記錄溢出（record_overflow）、未知CA（unknown_ca）、拒絕訪問（access_denied）等。
密文族和客戶證書：SSLv3.0和TLS存在少量差別，即TLS不支持Fortezza密鑰交換、加密算法和客戶證書。
certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時，計算的輸入有少許差別，但安全性相當。
加密計算：TLS與SSLv3.0在計算主密值（master secret）時采用的方式不同。
填充：用戶數據加密之前需要增加的填充字節。在SSL中，填充后的數據長度要達到密文塊長度的最小整數倍。而在TLS中，填充后的數據長度可以是密文塊長度的任意整數倍（但填充的最大長度為255字節），這種方式可以防止基于對報文長度進行分析的攻擊。

TLS的主要增強內容

TLS的主要目標是使SSL更安全，并使協議的規范更精確和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強內容：

更安全的MAC算法
更嚴密的警報
“灰色區域”規范的更明確的定義

TLS對于安全性的改進

對于消息認證使用密鑰散列法：TLS 使用“消息認證代碼的密鑰散列法”（HMAC），當記錄在開放的網絡（如因特網）上傳送時，該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。
增強的偽隨機功能（PRF）：PRF生成密鑰數據。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數據仍然是安全的。
改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。
一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現交換的證書類型。
特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應該發送某些警報進行記錄。

二、SSL/TLS 協議流程

2.1 對稱加密

對稱加密是指在加密和解密數據時使用相同的密鑰。發送者使用該密鑰將明文轉換為密文，而接收者則使用同一密鑰將密文還原為原始數據。

加密過程：發送方用密鑰 K 加密明文 P，得到密文 C = Encrypt(K, P)
解密過程：接收方必須用相同的密鑰 K 解密密文，得到 P = Decrypt(K, C)

關鍵點：雙方必須共享同一個密鑰 K，因此密鑰必須從發送方傳遞給接收方。

優點

速度快：對稱加密算法通常計算效率高，適合大數據量的加密。
實現簡單：算法相對簡單，資源占用較少。

缺點

密鑰分發問題：雙方必須共享同一個密鑰，如何安全地傳遞這個密鑰是一個關鍵問題。如果密鑰在傳輸過程中被截獲，數據安全就會受到嚴重威脅。

2.2 非對稱加密

非對稱加密（如 RSA、ECC）的核心特性是使用一對關聯的密鑰：公鑰（公開） 和 私鑰（私密）。在傳輸密鑰時，其邏輯與對稱加密完全不同，核心在于：公鑰可公開傳輸，私鑰絕不外傳，且主要用于安全傳輸對稱加密的密鑰。

公鑰：可以公開給任何人，用于加密數據或驗證數字簽名。
私鑰：僅由持有者保管，用于解密數據或生成數字簽名。

優點

安全的密鑰分發：無需通過安全渠道傳輸私密密鑰，公鑰可以公開分發，極大降低了密鑰泄露風險。
數字簽名：可以使用私鑰生成簽名，別人可以用公鑰驗證數據的完整性和真實性。

缺點

計算速度較慢：相比對稱加密，非對稱加密在計算上更為復雜，因此通常只用于加密小數據量或者用來交換對稱加密所使用的密鑰。

常見算法 如 RSA、ECC（橢圓曲線加密）等。

2.3 公鑰和私鑰

公鑰（Public Key）

定義：可以公開傳播的密鑰，任何人都能獲取。
特性：
- 用于加密數據或驗證數字簽名，但無法解密自己加密的內容。
- 相當于一把 “公開的鎖”，任何人都能用這把鎖加密信息，但只有持有對應鑰匙的人才能打開。

私鑰（Private Key）

定義：必須嚴格保密的密鑰，僅由所有者持有。
特性：
- 用于解密公鑰加密的數據或生成數字簽名，是加密體系的安全核心。
- 相當于 “唯一的鑰匙”，一旦泄露，整個加密體系將失效。

公鑰的用途

加密數據：發送方用接收方的公鑰加密信息，確保只有接收方（持有私鑰）能解密。
（例：HTTPS 中客戶端用服務器公鑰加密對稱密鑰）。
驗證簽名：用于驗證某段數據是否由對應的私鑰持有者生成（數字簽名的核心邏輯）。

私鑰的用途

解密數據：解公鑰加密的信息，獲取原始內容。
生成簽名：對數據進行簽名，證明數據由私鑰持有者發出，且未被篡改（如 SSL 證書簽名、Git commit 簽名）

2.4 TLS證書

TLS 證書的本質與核心作用

定義：TLS 證書是一種遵循 X.509 標準 的數字文檔，用于證明 “網絡實體（如服務器、客戶端）的身份” 與 “其公鑰的合法性”，本質是 公鑰與身份的綁定憑證

TLS 證書的關鍵組成部分（X.509 格式）

一張標準的 TLS 證書包含以下核心字段（以服務器證書為例）：

主體信息（Subject）：
- 證書持有者的身份標識，如域名（www.example.com）、組織名稱（企業）、國家 / 地區等。
- 關鍵字段：Common Name (CN) 或 Subject Alternative Name (SAN)，必須與訪問的域名嚴格匹配（如證書 CN 為example.com，無法用于www.example.com，會觸發瀏覽器警告）。
公鑰（Public Key）：
- 服務器用于非對稱加密的公鑰（如 RSA 2048 位或 ECC 密鑰），客戶端通過證書獲取該公鑰。
頒發機構（Issuer）：
- 簽發證書的 CA（Certificate Authority，證書權威機構）名稱，如 DigiCert、Let’s Encrypt。
有效期（Validity）：
- 證書生效的起止時間，過期后客戶端會拒絕連接（需重新申請證書）。
數字簽名（Signature）：
- CA 使用自身私鑰對證書內容（除簽名外的所有字段）進行哈希和加密，形成簽名。客戶端用 CA 的公鑰驗證簽名，確保證書未被篡改。
序列號（Serial Number）：
- CA 為證書分配的唯一標識符，用于吊銷時標識證書。

證書的頒發流程：CA 如何 “蓋章認證”？

服務器申請證書（CSR 生成）：
- 服務器生成密鑰對（公鑰 + 私鑰），并使用公鑰和身份信息生成證書簽名請求（CSR），包含域名、組織信息等。
CA 審核與簽名：
- CA 對服務器身份進行驗證（如域名所有權、企業合法性），審核通過后，用自身私鑰對 CSR 內容簽名，生成最終的 TLS 證書。
- CA 的信任基礎：CA 的根證書已預裝在操作系統、瀏覽器中（如 Windows、Chrome 內置數百個根 CA 證書），客戶端信任 CA 的簽名。
證書分發：
- 服務器將證書部署到服務器端，供客戶端在 TLS 握手時獲取。

2.5 SSL/TLS 握手過程

TLS（Transport Layer Security，傳輸層安全）握手是客戶端與服務器建立安全通信的核心過程，其目標是：協商加密算法、驗證身份、生成共享密鑰，確保后續數據傳輸的機密性和完整性
在這里插入圖片描述

第一階段：客戶端發起握手（ClientHello）

客戶端發送的關鍵信息：
- 版本號：聲明支持的 TLS 最高版本（如 TLS 1.2）。
- 隨機數（Client Random）：一個 32 字節的隨機數，用于后續生成密鑰。
- 密碼套件列表：客戶端支持的加密算法組合（如TLS_RSA_WITH_AES_256_GCM_SHA384，包含密鑰交換算法、對稱加密算法、哈希算法）。
- 擴展字段：可選信息（如 SNI 域名、壓縮算法等）。
核心目的：
告知服務器 “我想建立安全連接，并提供了可選的加密方案”。

第二階段：服務器響應（ServerHello + 證書 + 密鑰交換）

ServerHello 消息：
- 選擇版本：服務器從客戶端支持的版本中選擇最高兼容版本。
- 隨機數（Server Random）：另一個 32 字節隨機數，與 Client Random 共同構成密鑰生成的基礎。
- 選定密碼套件：從客戶端列表中選擇一個具體的加密方案。
- 擴展字段：返回服務器配置（如證書類型）。
服務器證書（Certificate）：
- 服務器發送自己的數字證書（含公鑰），證書由 CA（證書頒發機構）簽名，用于證明服務器身份。
- 客戶端驗證證書：檢查證書是否過期、CA 是否可信、域名是否匹配（防止中間人攻擊）。
密鑰交換相關消息（如 ServerKeyExchange）：
- 若密碼套件使用 RSA 等算法，服務器直接在證書中提供公鑰；若使用 DH（Diffie-Hellman）等算法，服務器會發送用于密鑰協商的參數。
ServerHelloDone：
服務器告知客戶端 “握手參數已發送完畢”。

第三階段：客戶端驗證與密鑰生成

客戶端驗證服務器身份：
- 通過服務器證書中的公鑰，驗證證書簽名是否有效（使用 CA 的根公鑰），確認服務器合法性。
生成預主密鑰（Pre-Master Secret）：
- 客戶端生成一個 48 字節的隨機數，用服務器公鑰加密（非對稱加密），發送給服務器（即ClientKeyExchange 消息）。
- 只有服務器能用私鑰解密該數據，獲取預主密鑰。
計算主密鑰（Master Secret）：
- 客戶端和服務器分別用以下數據生成相同的主密鑰：
  Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random)
  其中 PRF 是偽隨機函數，確保輸出的密鑰隨機性。
生成會話密鑰（Session Keys）：
- 主密鑰進一步衍生出多組密鑰，用于后續通信：
  - 加密密鑰：客戶端和服務器各一套，用于數據加密。
  - MAC 密鑰：用于計算消息認證碼（HMAC），確保數據完整性。

第四階段：密鑰驗證與握手完成

客戶端發送 ChangeCipherSpec：
告知服務器 “后續通信將使用新協商的加密算法和密鑰”。
客戶端發送 Finished 消息：
- 用剛生成的加密密鑰，對握手過程中的所有消息哈希值進行加密，發送給服務器（用于驗證密鑰正確性和握手完整性）。
服務器響應 ChangeCipherSpec：
確認切換到新的加密機制。
服務器發送 Finished 消息：
同樣用加密密鑰對握手消息哈希加密，回傳給客戶端，完成雙向驗證。

2.6 握手后的通信

握手完成后，客戶端與服務器用對稱加密算法（如 AES）和會話密鑰進行數據傳輸，每次通信都附帶 HMAC 確保完整性。
非對稱加密僅在握手階段用于密鑰交換，避免了大量數據加密的性能損耗。

密鑰生成：雙方協商，不對外暴露

TLS 握手時，對稱加密的會話密鑰由以下步驟生成（以 RSA 握手為例）：
1. 客戶端生成預主密鑰（隨機數），用服務器公鑰加密后發送（此時公鑰僅用于保護預主密鑰的傳輸）。
2. 服務器用私鑰解密得到預主密鑰，雙方再結合各自的隨機數（Client Random + Server Random），通過偽隨機函數（PRF）生成主密鑰（Master Secret）。
3. 主密鑰進一步衍生出對稱加密所需的會話密鑰（如客戶端發送密鑰、服務器發送密鑰等）。

整個過程中，會話密鑰的生成依賴于雙方的隨機數和預主密鑰，而預主密鑰在傳輸時被服務器公鑰加密，中間人無法破解（因無服務器私鑰），因此會話密鑰僅雙方可知

密鑰保密：不公開傳輸，僅內存持有

會話密鑰從未通過網絡公開傳輸，僅存在于客戶端和服務器的內存中，用于數據加密 / 解密。
即使網絡中截獲密文，由于不知道會話密鑰，也無法解密數據（對稱加密的安全性依賴于密鑰的保密性）。

在這里插入圖片描述

三、總結

TLS 的安全性與實踐要點

安全增強：
- 前向保密（FS）：使用 ECDHE 等算法，即使服務器私鑰泄露，歷史會話也無法解密。
- 證書透明度：強制 CA 將證書記錄在公開日志，防止偽造證書。
常見問題：
- 證書過期 / 域名不匹配：瀏覽器會提示 “連接不安全”，需及時更新證書或確保域名與證書 CN/SAN 一致。
- 中間人攻擊：若 CA 私鑰泄露或證書鏈驗證失敗，可能導致加密失效，需依賴瀏覽器內置的根 CA 信任機制防范。