目錄
- 前言
- 概念
- 對稱加密
- 非對稱加密
- 公鑰
- 單向加密
- 數字簽名
- 基礎
- 作用
- SSL/TLS 模型
- 運作
- 問題&解答
- 基本過程
- 握手階段
- 用戶端送出請求（ClientHello）
- 伺服器回應（SeverHello）
- 用戶端回應
- 伺服器的最後回應
- HTTPS 流程圖參考
前言
主要是自己學習SSL流程時的輔助了解筆記。
包括數字證書前面為什麼值得信任。
- 注意：多級CA還沒有時間去記錄，可能後期遇到再補。
-
概念
了解為主，非官方描述。
對稱加密
對稱加密：
- 明文 P，加上密碼 W 一混淆之後，變成密文 M。
- 如果不知道 W，則無法從 M 反推回 P。
- 例子：
- 異或。密鑰與明文異或得到密文。異或的特點使得，密文與密鑰進行異或，可以還原密文。
-
【TLS】-TLS/SSL筆記
非對稱加密
非對稱加密：
- 非對稱加密使用的密碼有一對：
- 一個稱為公鑰 Pub
- 一個稱為私鑰 Priv
- 明文 P，經過公鑰 Pub 加密後，變成密文 M。
- 密文 M 隻有私鑰 Priv 能解開。
- 若是結果私鑰 priv 加密，就隻由公鑰 pub 能解開。
公鑰
公鑰：公鑰，就是可以公開出去可以供所有人使用的密鑰。
私鑰：私鑰，需要保護好。
密碼：密碼，需要保護好。
單向加密
單向加密：
- 無法反推的加密。
- 如 hash。常用于比較明文是否被篡改。
數字簽名
知道公鑰和私鑰後。
基礎
作用
SSL/TLS 協定是為了解決這三大風險而設計：
- 所有資訊都是加密傳播，第三方無法竊聽。
- 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
- 配備身份證書，防止身份被冒充。
SSL/TLS 模型
運作
SSL/TLS 協定的基本思路是采用 公鑰加密法。
公鑰加密法：即是用戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。
問題&解答
- 如何保證公鑰不被篡改？
- 解決：将公鑰放在數字證書中。隻要證書是可信的，公鑰就是可信的。
- 公鑰加密計算量太大，如何減少耗用的時間？
- 解決：每一次對話（session），用戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密資訊。由于"對話密鑰"是對稱加密，是以運算速度非常快，而伺服器公鑰隻用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
- 數字證書驗證原理：
- 在握手階段，服務端會把服務端的公鑰放到 CA 頒發的數字證書中。
- CA 頒發數字證書，會給數字證書簽名。
- 簽名就是把數字證書經過 hash 算法得出 hash 值，然後用 CA 機構的私鑰給該 hash 值加密，這個加密值就是簽名。
- 服務端把數字證書、 CA 機構的簽名和哪一個 CA 機構發送到用戶端。
- 用戶端在自己信任的 CA 清單中找到和服務端發過來的 CA 機構，說明用戶端信任該機構。
- 然後用戶端把數字證書結果相同的 hash 算法得出 hash 值，且使用該 CA 機構的公鑰對服務端發來的簽名進行解密，若兩值相等，則說明證書可靠。
- 數字證書簽名和驗證如下圖：
-
【TLS】-TLS/SSL筆記
- SSL 過程中數字證書内容：
- 内容本端公鑰。
- 證書所有者。
- 證書的釋出機構。
- 證書的有效期。
- 等等。
基本過程
- 用戶端向伺服器端索要并驗證公鑰。
- 雙方協商生成"對話密鑰"。
- 雙方采用"對話密鑰"進行加密通信。
前兩步稱為 握手階段 （handshake）。
握手階段
握手階段涉及四次通信。
- 用戶端送出請求（ClientHello）
- 伺服器回應（SeverHello）
- 用戶端回應
- 伺服器的最後回應
握手階段都是明文通信。
用戶端送出請求（ClientHello）
用戶端先向伺服器發出加密通信的請求，主要向伺服器提供以下資訊：
- 支援的協定版本。
- 一個用戶端生成的随機數，稍後用于生成"對話密鑰"。
- 支援的加密方法，比如 RSA 公鑰加密。
- 支援的壓縮方法。
伺服器回應（SeverHello）
伺服器收到用戶端請求後，向用戶端發出回應，伺服器的回應包含以下内容：
- 确認使用的加密通信協定版本。
- 一個伺服器生成的随機數，稍後用于生成"對話密鑰"。
- 确認使用的加密方法，比如 RSA 公鑰加密。
- 伺服器證書。
- 要求用戶端提供用戶端證書。（這個取決于伺服器是否需要确認用戶端的身份）
用戶端回應
用戶端收到伺服器回應以後，首先驗證伺服器證書：
- 證書是否可信機構頒布；
- 證書中的域名與實際域名是否一緻；
- 證書是否已經過期。
若證書有問題，可以停止握手操作。
若證書沒問題，用戶端就會從證書中取出伺服器的公鑰。
然後，向伺服器發送下面三項資訊：
- 一個随機數（pre-master key）。該随機數用伺服器公鑰加密，防止被竊聽。
- 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
- 用戶端握手結束通知，表示用戶端的握手階段已經結束。這一項同時也是前面發送的所有内容的 hash 值，用來供伺服器校驗。
- 如果伺服器要求用戶端提供證書，用戶端發送證書及相關資訊。
小筆記：
- 握手階段産生三個随機數。保證生成的密鑰不會每次都一樣。
- 三個随機數通過一個密鑰導出器最終導出一個對稱密鑰。
- 三個随機數是因為雙方都不能保證對方的随機數是真的随機，是以自己也産生一個随機數，這樣就不能被猜出來。
伺服器的最後回應
伺服器收到用戶端的第三個随機數 pre-master key 之後，計算生成本次會話所用的"會話密鑰"。然後向用戶端發送以下資訊：
- 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
- 伺服器握手結束通知，表示伺服器的握手階段已經結束。
- 這一項同時也是前面發送的所有内容的 hash 值，用來供用戶端校驗。
握手結束後就可以繼續 http 協定繼續通信了。隻不過是加密會話而已。
- ssl 作用在應用層與傳輸層之間，它并不曉得應用層的東西。不必理會 url、header、body，應用層傳傳下來的資料到達傳輸層前，隻需要把整個資料包都加密就完事了。
HTTPS 流程圖參考
- 簡版
【TLS】-TLS/SSL筆記 - 目前主流的 TLS 的握手過程