不加密的HTTP面臨的風(fēng)險(xiǎn)
HTTP信息明文傳播，帶來了三大風(fēng)險(xiǎn)。
- 竊聽風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。
- 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。
- 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。
HTTPS通信的基本過程
- 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。
- 雙方協(xié)商生成 session密鑰。
- 雙方采用session密鑰進(jìn)行加密通信，就是普通HTTP協(xié)議之上的加密通信，通信內(nèi)容通過session密鑰加密。
第1、2步稱為TLS握手。
TLS 握手過程
客戶端請求 ClientHello
在這一步，客戶端主要向服務(wù)器提供以下信息。
（1） 支持的協(xié)議版本，比如TLS 1.0版。
（2） 一個(gè)客戶端生成的隨機(jī)數(shù)，稍后用于生成session密鑰。
（3） 支持的加密方法，比如RSA公鑰加密。
（4） 支持的壓縮方法。服務(wù)器回應(yīng) SeverHello
服務(wù)器的回應(yīng)包含以下內(nèi)容。
（1） 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
（2） 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成session密鑰。
（3） 確認(rèn)使用的加密方法，比如RSA公鑰加密。
（4） 服務(wù)器證書。
除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶端的身份，就會再包含一項(xiàng)請求，要求客戶端提供"客戶端證書"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
TLS handshake
- 客戶端響應(yīng)
（1） 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
（3） 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。
非對稱加密的缺點(diǎn) / 為什么要使用對稱秘鑰
公鑰加密計(jì)算量太大。造成CPU占用高、耗電、解密時(shí)間長的問題。
如何保證公鑰不被篡改？
使用數(shù)字證書機(jī)制。將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。
