寫在最前面（2025年2月7日）
DeepSeek分析結論
DeepSeek補充內容
隨著AI的成熟，我們更加方便的借助它來學習更完整的知識！
HTTPS協(xié)議是在HTTP協(xié)議的基礎上，增加了SSL/TLS加密協(xié)議，也就是說，在數(shù)據(jù)傳輸之前會對數(shù)據(jù)加密。
為什么使用HTTPS
防范偷窺
偷窺
防范篡改
篡改
使用HTTPS的優(yōu)缺點
優(yōu)點
- 數(shù)據(jù)加密，可以防止運營商劫持（無法避免DNS劫持）。
- 防止中間人攻擊。
- SEO方面，可以提高網(wǎng)站排名。
缺點
- 連接建立增加了2個RTT。
- 需要對數(shù)據(jù)加密，增加了耗時。
HTTPS的建立連接過程
TCP三次握手
- TCP的三次握手是必不可少的。
-
后續(xù)則根據(jù)不同算法來交換秘鑰。
TCP
使用RSA秘鑰交換
RSA exchange secret
- 客戶端生成48字節(jié)的預主秘鑰（pre_master_secret）。
- 用證書的公鑰加密。
- 發(fā)送給服務端，服務端收到后用私鑰解密。
- 雙發(fā)用預主秘鑰生成主密鑰。
使用DH秘鑰交換
DH算法原理
- 通信雙方（甲、乙）約定好算法參數(shù)：一個素數(shù)p作為模數(shù)、一個素數(shù)g作為基數(shù)，兩者都可對外公開。
- 甲選取一個秘密的自然數(shù)a，計算A = g^a % p，然后將A發(fā)送給乙。
- 乙選取一個秘密的自然數(shù)b，計算B = g^b % p，然后將B發(fā)送給甲。
- 甲用B和a計算出k = B ^ a % p，然后銷毀掉自然數(shù)a。
- 乙用A和b計算出k = A ^ b % p，然后銷毀掉自然數(shù)b。
- 雙方都得到了相同的k，那么就實現(xiàn)了不傳輸任何關鍵數(shù)據(jù)的情況下，交換關鍵數(shù)據(jù)。
- 即使拿到p、g、A、B，但是推算a或b是很困難的，自然也無法推算k；DH算法是利用了求解“離散對數(shù)問題”的困難來保證安全（ECDH 依賴的是求解“橢圓曲線離散對數(shù)問題”的困難，計算會比DH更復雜）。
- ps：可以簡單用p=23，g=5，a=6，b=8；來驗證下，雙方計算出來的k=4。
秘鑰交換過程
DH
- 服務端（乙）約定好素數(shù)p、g以及自己的秘密自然數(shù)b，并計算B，然后將p、g、B傳輸給客戶端。
- 客戶端（甲）拿到p、g、B后以及自己選取的秘密自然數(shù)a，計算出A，然后用證書的公鑰加密，傳輸給服務端。
- 服務端通過A和b計算出預主密鑰k，并銷毀b。
- 客戶端通過B和a計算出預主密鑰k，并銷毀a。
- 完成預主密鑰的交換。
消息的內容及作用
Client Hello
client hello
- 支持的協(xié)議版本
- 客戶端隨機數(shù)
- Session ID
- 所支持的密碼套件
- 壓縮數(shù)據(jù)
- 擴展名（extended_master_secret表示使用增強型主密鑰）
密碼套件
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TSL：使用的協(xié)議
- ECDHE：秘鑰交換算法
- RSA：簽名或驗證算法
- AES_128_CBC：數(shù)據(jù)加密算法
- SHA：消息驗證代碼
Server Hello
server hello
- 約定使用的協(xié)議及版本
- 服務端隨機數(shù)
- 約定使用的密碼套件
- Sessoin ID
- 壓縮數(shù)據(jù)
Server Certificate
server certificate
- 服務端返回給客戶端的證書，客戶端用根證書做驗證。
- 其中包含了非對稱加密算法的公鑰。
Server Key Exchange
server key exchange
- 只有使用DH算法做秘鑰交換才有的數(shù)據(jù)。
- 服務端計算的公鑰B
- DH算法需要的參數(shù)（已做簽名）
- ps：圖中使用的是ECDHE算法，原理和DH相似。
Client Key Exchange
client key exchange
- ps：圖中使用的是ECDHE算法。
RSA算法的Client Key Exchange
- 是用證書公鑰加密后的pre master secret密文。
DH算法的Client Key Exchange
- 是通過DH算法計算出來的客戶端公鑰A。
Finished
Finished
- 在握手的最后，會發(fā)送Encrypted Handshake Message，目的則是讓消息的接收者來判斷整個握手過程中的數(shù)據(jù)是否完整、正確。
- 第一個對稱加密后傳輸?shù)臄?shù)據(jù)。
- 驗證的內容是通過 PRF 算法計算出來的。
主密鑰計算方法
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)[0..47];
- pre_master_secret為上述秘鑰交換算法所交換的預主密鑰。
- ClientHello.random為Client Hello中的客戶端隨機數(shù)。
- ServerHello.random為Server Hello中的服務端隨機數(shù)。
- 主密鑰的長度是48字節(jié)。
增強型主密鑰計算方法
master_secret = PRF(pre_master_secret, "extended master secret", session_hash)[0..47];
- master secret被extended master secret替換。
- ClientHello.random + ServerHello.random被session_hash替換。
- 需要Client Hello的擴展名中包含extended_master_secret，并且Server Hello的擴展名中返回extended_master_secret，才會使用此計算方法。
會話秘鑰的計算方法
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random +SecurityParameters.client_random);
- 用于數(shù)據(jù)傳輸?shù)膶ΨQ加解密。
（由于每次會話都會重新計算會話秘鑰，每次會話的server_random和client_random都不同，所以即使是master_secret泄露或者破解，在不知道其他會話server_random和client_random的情況下，也不至于影響其他會話。）
HTTPS身份認證
- 客戶端根據(jù)本地的根證書，驗證從服務端來的證書信息，是否可信；如果可信，則使用證書中的非對稱加密的公鑰。
為什么需要證書驗證
- 中間人可以替換掉服務端返回的證書為自己的證書，那么客戶端使用的公鑰其實是中間人的公鑰。
為什么還有會其他（DH、ECDH等）算法作為秘鑰交換算法？
- 攻擊者，很有耐心，把所有嗅探到的傳輸數(shù)據(jù)都保存了下來。
- 攻擊者，過了很久通過一些手段，拿到了證書的私鑰。
1、入侵系統(tǒng)
2、利用協(xié)議的漏洞（如OpenSSL的漏洞）
3、威逼利誘
…… - 在握手過程中，我們會通過證書公鑰加密pre master secret，然后發(fā)送給服務端。
- 攻擊通過私鑰解密歷史傳輸?shù)膒re master secret，然后計算master key。
- 那么歷史所有的加密傳輸?shù)臄?shù)據(jù)都能解密拿到了o(╥﹏╥)o。
RSA算法交換秘鑰，不支持向前保密，所以就有了DH、ECDH算法交換秘鑰。
DH、ECDH怎么做到的向前保密
- 全程關鍵的數(shù)據(jù)沒有網(wǎng)絡傳輸，客戶端的秘密自然數(shù)a、服務端的秘密數(shù)據(jù)b、以及雙方計算出來的預主密鑰k。
- 利用素數(shù)p、素數(shù)g、公鑰A、公鑰B，去推算a、b非常困難，所以也很難推算出k。
- a、b數(shù)據(jù)不會保存，用完即銷毀，攻擊者基本沒可能獲取到。
- 即使攻擊者獲取到了當前的a、b、并計算出了k，那歷史的數(shù)據(jù)一樣不能解密。
