寫在最前面(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ù)一樣不能解密。