【轉】HTTPS淺析與抓包分析 | 老D部落格
0x00 HTTP之殤
- 資料明文傳輸，易嗅探
- 資料完整性無驗證，易篡改
- 網站身份無認證，易假冒
由此誕生HTTPS。
0x01 什麼是HTTPS
TLS是SSL的升級版
二圖勝千言：
//圖片來源於網路
作用：防嗅探，防篡改，身份認證
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三次握手
2. clienthello:
可以看出瀏覽器傳送了支援的協議版本TLS1.2，32位元組隨機數c，加密元件cipher等資訊給S。
3. serverhello:
可以看出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:
第一個cert是52pojie網站的證書，第二個cert是頒發者trustasia機構的證書。
這裡可以獲得證書的詳細資訊
5. serverkeyexchange和serverhellodone:
可以看出使用ECDH金鑰交換演算法，指定橢圓曲線secp256r1，還有傳送了DH演算法協商的公鑰給C。
6. Clientkeyexchange和client change cipher spec:
這裡C傳送了DH演算法協商的公鑰給S，以及加密了握手訊息給S進行驗證。
7. server change cipher spec:
服務端使用Ticket方式儲存session狀態，在Server Change Cipher Spec之前就需要傳送New Session Ticket訊息，這部分就不細說了。這裡S加密握手訊息給C進行驗證。
8. application data:
這裡可以看出雙方握手完畢，以後的訊息都進行對稱加密，已經無法看出明文了。
0x04 其他
- 由於握手流程導致https速度比http慢，本人認為其帶來的安全性更為重要，而速度雖然較慢，但是使用者幾乎感覺不到，而且有很多優化措施可以提升速度。
- 有了https並不能完全保證網站安全，安全是多因素，多環節的，即使有https，某個‘短板’就可以淪陷一個網站，並且https自身也非安全，如著名的心臟出血漏洞。
- https也非絕對防止MITM，如偽造證書，匯出明文密碼等。
0x05 結語
簡言之，能用https還是用https吧。由於時間倉促，可能有些細節遺漏或不準確，歡迎指正！
0x06 參考資料
轉自 https://laod.cn/hosts/https-capture-analysis.html