【轉】HTTPS淺析與抓包分析

NO IMAGE

0x00 HTTP之殤

  • 資料明文傳輸,易嗅探
  • 資料完整性無驗證,易篡改
  • 網站身份無認證,易假冒

由此誕生HTTPS。

 

0x01 什麼是HTTPS

HTTP   SSL/TLS

TLS是SSL的升級版

二圖勝千言:

//圖片來源於網路

https

【轉】HTTPS淺析與抓包分析

作用:防嗅探,防篡改,身份認證

 

0x02 https握手過程

建立https連線(明文),再用對稱加密傳輸資料。

TCP三次握手

C->S:[client hello] C傳送hello訊息(協議版本,隨機數c,加密元件列表等)給S,請求建立SSL會話。

S->C: [server hello]返回響應(確認加密元件,隨機數s等)。

S->C: [certificate]返回響應certificate(網站證書)。

S->C: [server key exchange]指定金鑰協商(交換)協議(金鑰協商方式),傳送金鑰協商(交換)演算法的公鑰給C。

S->C: [server hello done]傳送serverhellodone,開始C的金鑰協商。

C->S: [clientkeyexchange]C生成金鑰協商(交換)演算法公私鑰,傳送公鑰給S,此時C和S可以協商出相同的金鑰pre master secret,現在C和S可以通過c,s,pre master三個隨機數算出對稱加密的金鑰。(這裡本人還看到一個版本是C生成pre master secret 後用金鑰交換/協商演算法加密傳送到S,本人認為不需要傳送,S通過C傳送的金鑰協商的公鑰和自己生成的一個隨機數xs可以自己計算出這個pre master secret。還有一個版本是對稱加密的金鑰是C用S的證書公鑰加密給S用私鑰解密獲得,這裡本人認為此對稱金鑰S也可由c,s,pre master自己生成不需要C傳送。)

C->S: [changecipherspec]通知S此訊息以後C以加密方式傳送資料。

C->S: C用生成的對稱金鑰加密之前所有握手訊息hash,傳送給S解密驗證hash。

S->C: [changecipherspec]通知C此訊息後S以加密方式傳送資料。

S->C: S用對稱金鑰加密之前所有握手訊息hash,傳送給C進行解密驗證hash。

========================================

開始對稱加密傳輸資料……(Application Data)

========================================

 

0x03 抓包分析https握手流程

以瀏覽器開啟https://www.52pojie.cn為例

1. dns解析和tcp三次握手

【轉】HTTPS淺析與抓包分析

 

2. clienthello:

 

【轉】HTTPS淺析與抓包分析

可以看出瀏覽器傳送了支援的協議版本TLS1.2,32位元組隨機數c,加密元件cipher等資訊給S。

3. serverhello:

【轉】HTTPS淺析與抓包分析

可以看出S選擇了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密元件,解釋如下:
金鑰交換演算法,用於決定客戶端與伺服器之間在握手的過程中如何認證,用到的演算法包括RSA,Diffie-Hellman,ECDH,PSK等,這裡選擇了ECDHE。

加密演算法,用於加密訊息流,該名稱後通常會帶有兩個數字,分別表示金鑰的長度和初始向量的長度,比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256。這裡選擇了AES。

報文認證資訊碼(MAC)演算法,用於建立報文摘要,確保訊息的完整性(沒有被篡改),演算法包括MD5,SHA等。這裡選擇了SHA384。

PRF(偽隨機數函式),用於生成“master secret”。

S還傳送了32位元組隨機數s。

 

4.certificate:

【轉】HTTPS淺析與抓包分析

 

第一個cert是52pojie網站的證書,第二個cert是頒發者trustasia機構的證書。

 

【轉】HTTPS淺析與抓包分析

這裡可以獲得證書的詳細資訊

 

5. serverkeyexchange和serverhellodone:

【轉】HTTPS淺析與抓包分析

 

可以看出使用ECDH金鑰交換演算法,指定橢圓曲線secp256r1,還有傳送了DH演算法協商的公鑰給C。

 

6. Clientkeyexchange和client change cipher spec:

【轉】HTTPS淺析與抓包分析

這裡C傳送了DH演算法協商的公鑰給S,以及加密了握手訊息給S進行驗證。

 

7. server change cipher spec:

【轉】HTTPS淺析與抓包分析

服務端使用Ticket方式儲存session狀態,在Server Change Cipher Spec之前就需要傳送New Session Ticket訊息,這部分就不細說了。這裡S加密握手訊息給C進行驗證。

 

8. application data:

【轉】HTTPS淺析與抓包分析

這裡可以看出雙方握手完畢,以後的訊息都進行對稱加密,已經無法看出明文了。

 

0x04 其他

  • 由於握手流程導致https速度比http慢,本人認為其帶來的安全性更為重要,而速度雖然較慢,但是使用者幾乎感覺不到,而且有很多優化措施可以提升速度。
  • 有了https並不能完全保證網站安全,安全是多因素,多環節的,即使有https,某個‘短板’就可以淪陷一個網站,並且https自身也非安全,如著名的心臟出血漏洞。
  • https也非絕對防止MITM,如偽造證書,匯出明文密碼等。

 

0x05 結語

簡言之,能用https還是用https吧。由於時間倉促,可能有些細節遺漏或不準確,歡迎指正!

 

0x06 參考資料

https://xianzhi.aliyun.com/forum/read/2037.html

www.droidsec.cn/淺析https中間人攻擊與證書校驗/


https://klionsec.github.io/2017/07/31/https-learn/

kb.cnblogs.com/page/530044/