0.HTTP之殤

• 數據明文傳輸，易嗅探
• 數據完整性無驗證，易篡改
• 網站身份無認證，易假冒

由此誕生HTTPS。

1.什麽是HTTPS

• HTTP + SSL/TLS
• TLS是SSL的升級版

• 作用：防嗅探，防篡改，身份認證

2.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）

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

3.抓包分析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:

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

5.其他

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

6.結語

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

7.參考資料

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/

【轉】https淺析與抓包