SSL/TLS

干啥的？ ：SSL（Secure Sockets Layer） 和 TLS（Transport Layer Security） 是一種用于在網絡通信中提供安全性的協議。它們的主要目的是在客戶端（如瀏覽器）和服務器之間建立加密連接，確保數據傳輸的安全性和隱私性。

SSL 是由 Netscape 開發的一種早期的安全協議，TLS 是 SSL 的繼任者，修復了 SSL 中的許多安全漏洞。提供了更安全和高效的通信機制。
SSL有多個版本（SSL 1.0、2.0、3.0），但因安全性問題，SSL 3.0 及以下版本已被廢棄。
TLS版本包括 TLS 1.0、1.1、1.2 和 1.3。當前推薦使用 TLS 1.2 或更高版本，因為它們提供了更好的安全性。

SSL/TLS工作原理的核心步驟

握手階段（Handshake Protocol）

（1）客戶端向服務器發送一個 ClientHello 消息，包含以下信息：
● 支持的 SSL/TLS 版本（如 TLS 1.2 或 TLS 1.3）。
● 支持的加密套件列表（Cipher Suites），包括加密算法和哈希算法。
● 客戶端隨機數（Client Random），用于后續密鑰生成。
● 可選的擴展字段（如支持的壓縮方法、ALPN 協議等）。

（2）服務器選擇一個雙方都支持的加密套件，并返回一個 ServerHello 消息，包含以下信息：
● 確定的 TLS 版本。
● 選定的加密套件。
● 隨機數（Server Random），用于后續密鑰生成。
● 可選的會話 ID（Session ID），用于會話恢復。

（3）服務器證書（Server Certificate）
服務器向客戶端發送其數字證書，包含公鑰和其他身份信息。

（4）客戶端驗證證書

（5）Server Key Exchange（可選）
如果選定的加密套件需要額外的密鑰參數（如 Diffie-Hellman 參數），服務器會發送 Server Key Exchange 消息。

（6）Server Hello Done
服務器發送 Server Hello Done 消息，表示服務器已完成握手消息的發送。

（7）預主密鑰交換（Key Exchange）

預主密鑰（Pre-Master Secret）→ 主密鑰（Master Secret）→ 會話密鑰（Session Keys）
● 預主密鑰的作用：作為初始的秘密值，提供一個隨機且安全的變量因子生成主密鑰。
● 主密鑰的作用：作為中間密鑰，提供更高的安全性和隨機性擴展。
● 會話密鑰的作用：實際用于數據加密和解密。
為啥不用預主密鑰 直接生成 會話密鑰，非要引入 主密鑰呢？
1、增強安全性：預主密鑰（Pre-Master Secret） + 客戶端隨機數（Client Random）+ 服務器隨機數（Server Random）生成主密鑰（Master Secret），增加了復雜性和不可預測性。
2、提供隨機性擴展：預主密鑰的長度通常是固定的（例如 48 字節），而主密鑰可以通過 PRF 擴展為任意長度。
客戶端隨機數 + 服務器隨機數 可以很容易被獲取，生成主密鑰為啥還用他？
雖然客戶端隨機數（Client Random）和服務器隨機數（Server Random）在握手階段會被明文傳輸，看似容易被獲取，但它們在主密鑰生成中的作用是不可替代的。
1、這些值本身是動態生成的，并且每次連接都會不同。這種動態性使得攻擊者無法提前預測或重用之前的密鑰生成過程。
2、客戶端隨機數和服務器隨機數確保了每次連接的唯一性。如果攻擊者試圖重放之前的通信數據，新的隨機數會使得生成的主密鑰和會話密鑰完全不同，從而阻止重放攻擊。
3、支持前向安全性，即使長期密鑰（如服務器私鑰）被泄露，攻擊者也無法推導出之前的主密鑰和會話密鑰。

常用密鑰交換算法

● RSA 密鑰交換
原理：客戶端生成一個隨機的預主密鑰（Pre-Master Secret）。使用服務器的公鑰（從證書中提取）加密預主密鑰，并發送給服務器。服務器使用自己的私鑰解密，獲得預主密鑰。
優點：實現簡單，易于部署。
缺點：如果服務器私鑰泄露，所有歷史通信都可能被解密。
● Diffie-Hellman 密鑰交換（DH 、ECDH、ECDHE）
Diffie-Hellman 加密協議介紹 （DH，DHE，ECDHE）

（8）生成會話密鑰（Key Derivation）
● 計算主密鑰（Master Secret）
預主密鑰（Pre-Master Secret） + 客戶端隨機數（Client Random）+ 服務器隨機數（Server Random），通過特定算法計算出主密鑰（Master Secret）。

主密鑰計算的位置
客戶端 和 服務器 各自獨立完成主密鑰（Master Secret）的計算。
為什么不在一個地方計算？
安全性：如果主密鑰只在一方計算，另一方需要通過網絡接收主密鑰，這會增加被竊聽或篡改的風險。
如果不一致怎么辦？
主密鑰計算完成后，客戶端和服務端會進一步使用主密鑰派生出會話密鑰，并用這些會話密鑰加密后續的通信數據。如果主密鑰不一致，生成的會話密鑰會不同，加解密會出問題，從而檢測到問題。

● 派生出會話密鑰（Session Keys）
主密鑰派生出其他秘鑰
● 會話密鑰 用于 數據加密
● MAC密鑰 用于 完整性驗證

（9）更改加密狀態（ChangeCipherSpec）
ChangeCipherSpec 消息本身非常簡單，只包含一個字節的數據。其值固定為 0x01，表示“切換加密模式”的指令。
客戶端和服務器分別發送 ChangeCipherSpec 是用來通知對方 “我已經準備好使用我們協商好的加密算法和密鑰進行加密通信了。”

SSL/TLS 協議規定：
● 如果 ChangeCipherSpec 消息在網絡中丟失或亂序，TCP 層會自動重傳或重新排序。
● 客戶端必須先發送 ChangeCipherSpec 和 Finished 消息。服務器在接收到這些消息后，才會發送自己的 ChangeCipherSpec 和 Finished 消息。

1、客戶端發送 ChangeCipherSpec
客戶端完成密鑰協商后，發送 ChangeCipherSpec 消息，表示將切換到加密狀態。
2、客戶端發送 Finished 消息
緊接著 ChangeCipherSpec，客戶端發送加密的 Finished 消息。（Finished消息是第一個使用協商好的加密算法和會話密鑰保護的消息）
3、服務器接收并處理
● 服務器接收到客戶端的 ChangeCipherSpec 后，切換到加密狀態。
● 服務器嘗試解密客戶端的 Finished 消息。如果解密成功且驗證Finished消息成功，則說明：客戶端已經完成了密鑰協商且和服務端秘鑰一致。且客戶端發送了 ChangeCipherSpec 消息，并切換到了加密狀態。
4、服務器發送 ChangeCipherSpec
服務器完成密鑰協商后，發送 ChangeCipherSpec 消息給客戶端，表示將切換到加密狀態。
5、服務器發送 Finished 消息：
緊接著 ChangeCipherSpec，服務器發送加密的 Finished 消息。
6、客戶端接收并處理：
● 客戶端接收到服務器的 ChangeCipherSpec 后，切換到加密狀態。
● 客戶端嘗試解密服務器的 Finished 消息。如果解密成功且驗證Finished消息成功，則說明：服務器已經完成了密鑰協商且和客戶端秘鑰一致。且服務端已經發送了 ChangeCipherSpec 消息，并切換到了加密狀態。

服務器切換到加密狀態的時機
第一次切換：當服務器接收到客戶端的 ChangeCipherSpec 消息后，切換到加密狀態以解密客戶端的 Finished 消息。
第二次切換：當服務器發送自己的 ChangeCipherSpec 消息后，再次確認切換到加密狀態以發送加密的 Finished 消息。
服務器的加密狀態切換是雙向的，既依賴于客戶端的行為（接收到客戶端的 ChangeCipherSpec），也依賴于自身的動作（發送自己的 ChangeCipherSpec）。這種設計確保了握手過程的安全性和一致性。
客戶端切換到加密狀態的時機
第一次切換：當客戶端完成密鑰協商后，發送自己的 ChangeCipherSpec 消息時，切換到加密狀態以發送加密的 Finished 消息。
第二次切換：當客戶端接收到服務器的 ChangeCipherSpec 消息后，再次確認切換到加密狀態以解密服務器的加密消息。

如果一方沒有收到對方的 ChangeCipherSpec 消息怎么辦？
如果一方沒有及時收到對方的 ChangeCipherSpec 消息，通常會有以下幾種處理方式：
超時重傳：如果一方在合理的時間內沒有收到對方的 ChangeCipherSpec 消息，它可能會重新發送 ChangeCipherSpec 消息，或者觸發握手超時機制，重新發起握手。
握手失敗：如果多次重傳后仍未收到對方的響應，握手將被視為失敗，連接會被關閉。

（10）握手完成（Finished）
Finished 消息包含一個基于主密鑰，標簽，握手歷史的哈希值，用于驗證完整性，確保握手未被篡改。
● 標簽是一個固定的字符串，客戶端：“client finished”，服務器：“server finished”
● 握手消息（Handshake Messages）是指從 Client Hello 到 Change Cipher Spec 之間的所有握手消息的拼接內容。

具體流程
參考上文ChangeCipherSpec的流程，如果雙方的 Finished 消息匹配，則握手成功，進入加密通信模式。

如何驗證Finished消息?
1、客戶端接收到服務器發送的 Finished 消息后，提取其中的 VerifyData。
2、客戶端使用相同的 PRF 算法，結合（主密鑰，標簽，握手歷史記錄）重新計算 VerifyData：
3、如果客戶端計算出的 VerifyData 與接收到的 VerifyData 一致，則說明：
● 服務器使用的主密鑰正確。
● 握手過程中所有消息未被篡改。
同樣地，服務器驗證客戶端的 Finished 消息也如上步驟。如果任一方的驗證失敗，握手將終止，連接會被關閉。

加密通信階段（Encrypted Communication Phase）

（1）對稱加密
使用握手階段生成的會話密鑰（Session Key）對數據進行加密和解密。常見的對稱加密算法包括 AES、ChaCha20 等。對稱加密算法（如 AES）效率高，適合大規模數據傳輸。
（2）消息認證碼（MAC）
每條消息都附帶一個 MAC（Message Authentication Code），用于確保數據的完整性。
（3）重新協商（可選）
如果客戶端和服務器希望在未來的連接中快速恢復會話，可以使用會話 ID 或會話票據（Session Ticket）機制。
會話恢復避免了重新執行完整的握手過程，從而提高了性能。

會話恢復（Session Resumption）

為了提高效率，SSL/TLS 提供了會話恢復機制，避免每次連接都重新進行完整的握手。
（1）會話 ID
在握手階段，服務器分配一個唯一的會話 ID。
客戶端可以在后續連接中使用該會話 ID 來恢復之前的會話。
（2）會話票據（Session Ticket）
服務器可以將加密的會話狀態存儲在客戶端（稱為會話票據）。
客戶端在后續連接中提交會話票據以恢復會話。

---

SSH

Secure Shell Protocol（安全外殼協議），SSH 可以創建一個加密的“隧道”，將其他非加密協議（如 HTTP、SMTP）封裝在其中，確保數據傳輸的安全性。

SSH 加密機制的核心步驟

1）建立 TCP 連接
客戶端與服務器通過 TCP 協議建立初始連接。這是所有后續通信的基礎。

2）版本協商
雙方交換 SSH 協議版本信息（如 SSH-2.0），確保雙方使用相同的協議版本。

3）算法協商
客戶端和服務器協商以下參數：
● 密鑰交換算法： 如 Diffie-Hellman（DH）、ECDH 等。
● 加密算法： 如 AES、ChaCha20 等。
● MAC 算法： 如 HMAC-SHA256 等。
● 壓縮算法： 如 zlib 等。

4）密鑰交換
（1）生成共享密鑰
使用 DH 或 ECDH 算法進行密鑰交換。雙方基于公鑰密碼學生成一個共享的秘密值（Shared Secret）。
（2）計算會話密鑰
根據共享的秘密值、交換的隨機數以及其他參數，派生出會話密鑰（Session Key）。會話密鑰用于后續的對稱加密通信。

如何驗證共享秘密的一致性？
1、共享秘密被用來派生出會話密鑰，如果雙方能夠成功解密對方的消息，則說明共享秘密一致。（這條能說明不能解密那么他們肯定是不一致的，但是能解密不一定就代表是一致的，因為不一定保證解密內容是對的的）
2、消息認證碼（MAC）：每條消息附帶一個 MAC 值，用于驗證消息的完整性和共享秘密的一致性。（MAC能保證解密內容也是對的，結合第一條，既能解密，解密內容又是對的，這樣就保證了共享秘密一定是一致的）

4）客戶端驗證服務器的身份
1、服務器向客戶端發送自己的公鑰證書（通常是基于 RSA 或 ECDSA 的公鑰）。
2、客戶端驗證服務器的公鑰是否可信（通常通過 CA 或本地信任存儲）。
3、如果驗證失敗，連接將被終止。

5）客戶端向服務器證明自己的身份
● 密碼認證： 用戶輸入密碼，服務器驗證密碼是否正確。
● 公鑰認證：
1、服務器生成一段隨機數據（挑戰數據），并將其發送給客戶端。
2、客戶端收到挑戰數據后，用自己的私鑰對這段數據進行簽名。
3、客戶端將簽名發送回服務器。
4、服務器用客戶端的公鑰（私鑰保存在客戶端，公鑰上傳到服務器，這就是我們平時配置的公鑰）解密簽名，得到原始的哈希值。服務器重新計算挑戰數據的哈希值，并與解密后的哈希值進行比較。如果兩者一致，則證明簽名有效，客戶端身份驗證成功。如果不一致，則驗證失敗。

為什么需要挑戰數據？
防止重放攻擊：每次認證過程中的數據都是唯一的，攻擊者無法通過重放舊的簽名來通過認證。
驗證私鑰持有者：只有擁有對應私鑰的客戶端才能生成有效的簽名，從而證明自己是合法用戶。

● 其他方式： 如鍵盤交互認證、GSSAPI 認證，單點登錄（SSO）等。

6）加密通信
客戶端和服務器開始使用協商好的對稱加密算法和共享的秘鑰（session key）加密所有后續通信。
具體包括：
● 數據加密： 所有傳輸的數據都經過對稱加密，確保機密性。
● 消息認證： 每條消息都附帶 MAC（消息認證碼），確保數據的完整性和防止篡改。
● 序列號： 每條消息都有唯一的序列號，防止重放攻擊。

SSH優點
● 安全性高，適合私有數據的傳輸。
● 提供靈活的身份驗證方式。
● 支持雙向通信（既可讀取也可寫入）。

SSH缺點
● 配置較復雜（私鑰保存在客戶端，公鑰上傳到服務器）。
● 可能受防火墻限制（需要開放 SSH 端口，默認為 22）。

SSH使用場景
1、遠程登錄：系統管理員可以通過 SSH 登錄到遠程服務器，執行各種管理任務。 主要因為：SSH確保在客戶端與服務器之間傳輸的所有數據（包括登錄憑據、命令和輸出）都經過加密。即使網絡環境不安全（如公共 Wi-Fi），也能保證通信的安全。
2、文件傳輸：SSH 提供了基于其加密通道的文件傳輸協議（SFTP），可以安全地上傳或下載文件。 主要因為：和1原因一致。
3、SSH 支持端口轉發功能 ： 主要因為：SSH 協議本身提供了一個安全的加密通道，所有通過該通道傳輸的數據都會被加密。當使用端口轉發時，SSH 將其他協議的流量（如 HTTP、SMTP）封裝到其加密通道中進行傳輸。這種加密機制確保了轉發的流量在傳輸過程中不會被竊聽或篡改。

SSH 和 SSL 區別

使用用途
SSH 直接綁定到特定的應用場景（如遠程登錄、文件傳輸），而 SSL/TLS 是一個通用的中間層協議，可以封裝任意應用層協議。用于保護應用層協議數據傳輸安全性。廣泛應用于HTTPS、電子郵件（SMTP、IMAP、POP3）、文件傳輸（FTPS）等場景。

什么是命令行訪問？
命令行訪問是指用戶通過終端或命令行界面與遠程服務器進行交互。
SSH 如何實現安全的命令行訪問？
SSH 自身的安全性
什么是加密通信通道？
加密通信通道是指在客戶端和服務器之間建立一個專用的、加密的連接。所有通過該通道傳輸的數據都會被加密，防止被第三方竊聽或篡改。

握手過程
SSL/TLS 主要面向服務器級認證（基于 X.509 證書），SSH 的身份驗證機制主要面向用戶級認證（如公鑰或密碼）。
SSL/TLS 的核心步驟并不強制要求驗證客戶端身份，而是根據實際場景靈活選擇是否啟用雙向認證。SSH 的核心步驟要求驗證客戶端身份。

SSL/TLS：
使用證書機制驗證服務器身份。
密鑰交換算法包括 RSA、DH、ECDH 等。
握手完成后進入加密通信階段。

SSH：
使用證書機制驗證服務器身份。
密鑰交換算法包括 DH 或 ECDH 。
支持多種用戶身份驗證方式（如密碼、公鑰、鍵盤交互）。
在握手完成后進入加密通信階段。

記錄層協議
SSL/TLS：記錄層協議復雜，支持多種內容類型（如應用數據、警報、握手消息）。能夠封裝任意應用層協議。
SSH：記錄層協議簡單，主要用于傳輸加密數據和 MAC 值。不區分不同的應用層協議。

性能和優化方向的不同
SSL/TLS：更注重大規模數據傳輸的性能優化。支持會話恢復（Session Resumption）以減少握手開銷。
SSH：更注重交互式會話的性能優化。支持壓縮功能以提高傳輸效率。