• 前言
• 概念
  • 對稱加密
  • 非對稱加密
  • 公鑰
  • 單向加密
  • 數字簽名
• 基礎
  • 作用
  • SSL/TLS 模型
  • 運作
    • 問題&解答
    • 基本過程
  • 握手階段
    • 客戶端發出請求（ClientHello）
    • 伺服器迴應（SeverHello）
    • 客戶端迴應
    • 伺服器的最後迴應
• HTTPS 流程圖參考

前言

主要是自己學習SSL流程時的輔助理解筆記。
包括數字證書前面為什麼值得信任。

• 注意：多級CA還沒有時間去記錄，可能後期遇到再補。

參考：

• https://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
• 數字證書原理

李柱明部落格：https://www.cnblogs.com/lizhuming/p/15487016.html

概念

理解為主，非官方描述。

對稱加密

對稱加密：

• 明文 P，加上密碼 W 一混淆之後，變成密文 M。

• 如果不知道 W，則無法從 M 反推回 P。

• 例子：

  • 異或。金鑰與明文異或得到密文。異或的特點使得，密文與金鑰進行異或，可以還原密文。

非對稱加密

非對稱加密：

• 非對稱加密使用的密碼有一對：

  • 一個稱為公鑰 Pub
  • 一個稱為私鑰 Priv

• 明文 P，經過公鑰 Pub 加密後，變成密文 M。

• 密文 M 只有私鑰 Priv 能解開。

• 若是結果私鑰 priv 加密，就只由公鑰 pub 能解開。

公鑰

公鑰：公鑰，就是可以公開出去可以供所有人使用的金鑰。
私鑰：私鑰，需要保護好。
密碼

單向加密

單向加密：

• 無法反推的加密。
• 如 hash。常用於比較明文是否被篡改。

數字簽名

知道公鑰和私鑰後。

基礎

作用

SSL/TLS 協議是為了解決這三大風險而設計：

• 所有資訊都是加密傳播，第三方無法竊聽。
• 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。
• 配備身份證書，防止身份被冒充。

SSL/TLS 模型

運作

SSL/TLS 協議的基本思路是採用 公鑰加密法。
公鑰加密法：即是客戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。

問題&解答

1. 如何保證公鑰不被篡改？

   • 解決：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

2. 公鑰加密計算量太大，如何減少耗用的時間？

   • 解決：每一次對話（session），客戶端和伺服器端都生成一個"對話金鑰"（session key），用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

3. 數字證書驗證原理：

   • 在握手階段，服務端會把服務端的公鑰放到 CA 頒發的數字證書中。
   • CA 頒發數字證書，會給數字證書籤名。
   • 簽名就是把數字證書經過 hash 演算法得出 hash 值，然後用 CA 機構的私鑰給該 hash 值加密，這個加密值就是簽名。
   • 服務端把數字證書、 CA 機構的簽名和哪一個 CA 機構傳送到客戶端。
   • 客戶端在自己信任的 CA 列表中找到和服務端發過來的 CA 機構，說明客戶端信任該機構。
   • 然後客戶端把數字證書結果相同的 hash 演算法得出 hash 值，且使用該 CA 機構的公鑰對服務端發來的簽名進行解密，若兩值相等，則說明證書可靠。
   • 數字證書籤名和驗證如下圖：

4. SSL 過程中數字證書內容：

   1. 內容本端公鑰。
   2. 證書所有者。
   3. 證書的釋出機構。
   4. 證書的有效期。
   5. 等等。

基本過程

1. 客戶端向伺服器端索要並驗證公鑰。
2. 雙方協商生成"對話金鑰"。
3. 雙方採用"對話金鑰"進行加密通訊。

前兩步稱為 握手階段 （handshake）。

握手階段

握手階段涉及四次通訊。

• 客戶端發出請求（ClientHello）
• 伺服器迴應（SeverHello）
• 客戶端迴應
• 伺服器的最後迴應

握手階段都是明文通訊。

客戶端發出請求（ClientHello）

客戶端先向伺服器發出加密通訊的請求，主要向伺服器提供以下資訊：

1. 支援的協議版本。
2. 一個客戶端生成的隨機數，稍後用於生成"對話金鑰"。
3. 支援的加密方法，比如 RSA 公鑰加密。
4. 支援的壓縮方法。

伺服器迴應（SeverHello）

伺服器收到客戶端請求後，向客戶端發出迴應，伺服器的迴應包含以下內容：

1. 確認使用的加密通訊協議版本。
2. 一個伺服器生成的隨機數，稍後用於生成"對話金鑰"。
3. 確認使用的加密方法，比如 RSA 公鑰加密。
4. 伺服器證書。
5. 要求客戶端提供客戶端證書。（這個取決於伺服器是否需要確認客戶端的身份）

客戶端迴應

客戶端收到伺服器迴應以後，首先驗證伺服器證書：

• 證書是否可信機構頒佈；
• 證書中的域名與實際域名是否一致；
• 證書是否已經過期。

若證書有問題，可以停止握手操作。

若證書沒問題，客戶端就會從證書中取出伺服器的公鑰。

然後，向伺服器傳送下面三項資訊：

1. 一個隨機數（pre-master key）。該隨機數用伺服器公鑰加密，防止被竊聽。
2. 編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
3. 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的 hash 值，用來供伺服器校驗。
4. 如果伺服器要求客戶端提供證書，客戶端傳送證書及相關資訊。

小筆記：

• 握手階段產生三個隨機數。保證生成的金鑰不會每次都一樣。
• 三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。
• 三個隨機數是因為雙方都不能保證對方的隨機數是真的隨機，所以自己也產生一個隨機數，這樣就不能被猜出來。

伺服器的最後迴應

伺服器收到客戶端的第三個隨機數 pre-master key 之後，計算生成本次會話所用的"會話金鑰"。然後向客戶端傳送以下資訊：

1. 編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。

2. 伺服器握手結束通知，表示伺服器的握手階段已經結束。

   • 這一項同時也是前面傳送的所有內容的 hash 值，用來供客戶端校驗。

握手結束後就可以繼續 http 協議繼續通訊了。只不過是加密會話而已。

• ssl 作用在應用層與傳輸層之間，它並不曉得應用層的東西。不必理會 url、header、body，應用層傳傳下來的資料到達傳輸層前，只需要把整個資料包都加密就完事了。

HTTPS 流程圖參考

• 簡版
  

• 目前主流的 TLS 的握手過程