HTTPS協(xié)議

寫在最前面(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ù)一樣不能解密。
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。