1. 初步認識https協議

??屬于應用層

??相較于http協議，https在應用層多了一層加密層，為了保證數據安全

??簡單理解：https就是對http的加密和解密

---

2. 中間人攻擊

??數據在傳輸過程中，遭第三方篡改。

---

3. 加密方式

??對稱加密：雙方使用同一個密鑰進行加密和解密

特點：通信速度快

??非對稱加密：需要兩個密鑰，一共公開 → 公鑰， 一個私有 → 私鑰

特點：慢

---

4. 加密方案

4.1 方案一：只使用對稱加密

首次申請時，client端需要將對稱密鑰X，發給服務端，該過程會被中間人攻擊，因此不安全，所以pass

4.2 方案二：只使用非對稱加密

只能保證單向數據安全，所以pass

4.3 方案三：雙方都使用非對稱加密

通信的雙方將各自的公鑰傳給對方，然后開始通信。

流程：

1. server端將公鑰s傳給client端

2. client端將公鑰c傳給server端

3. client端將數據+公鑰s傳給server端，server端用自己的私鑰s對數據進行解密

4. server端拿著響應+公鑰c傳給client端，client?端用自己的私鑰c對數據進行解密

缺陷：

1.本質還是不安全的，稍后解釋

2.通信速度太慢了

4.4 方案四：非對稱加密 + 對稱加密

流程：

1. server端將公鑰s傳給client端，

2. client端將對稱密鑰X + 公鑰s形成密文數據傳給 server端

3. server端拿著自己的私鑰s對密文數據進行解密，這樣server端也就拿到了 對稱密鑰X，

4. 雙方使用對稱密鑰x進行通信

缺陷：

中間人可以篡改由server端發送的公鑰s，篡改為自己的公鑰m，client端發送密文數據時， 發送的是：對稱密鑰X + 公鑰m，中間人就可以拿自己的私鑰m解密，獲得對稱密鑰X

后續server端和client端通信時，中間人就一覽無余了，這也是方案三的缺陷

注：

中間人為了隱藏其存在，將自己解出來的對稱密鑰X和原先的公鑰S 進行加密，再傳給server端，此時雙方都不知道數據已經被中間人篡改過了

4.5 最終方案：非對稱加密 + 對稱加密 + 證書認證

現存方案問題：client端無法驗證收到公鑰s的合法性。

引入新概念：

??摘要：將數據通過散列函數(哈希算法)得到的散列值稱為摘要

??簽名：將獲得的摘要通過簽名者的私鑰A進行加密，得到的數據稱為簽名

注：簽名者是CA機構 or CA子機構，后續介紹

??證書：銘文數據 + 簽名的組合稱為證書

??驗證：client端將 銘文數據通過散列函數得到的散列值H1，client端通過簽名者的公鑰A對簽名進行解密，得到散列值H2，判斷H1和H2是否相等來驗證client端收到的公鑰s是否合法。

方案五的通信流程：

1. server端拿著域名、公鑰s、申請者向CA機構申請證書，

注：域名、公鑰s、申請者等其他信息稱為sever端的銘文數據

2. CA機構根據server端的銘文數據通過散列函數獲得散列值，對散列值進行加密后獲得簽名，將銘文數據和簽名數據附加在一起形成證書，然后再向server端頒發證書

3. 此時http服務器建立完畢，就可以正式上線給用戶使用了

4. 用戶端發起http申請，獲得攜帶證書的公鑰

5. 驗證公鑰的合法性，將 銘文數據通過散列函數得到的散列值 與 通過CA機構的公鑰S解密后的散列值 進行對比，來驗證合法性

注：所有的瀏覽器都內置了CA的公鑰

6. 一旦公鑰可信任，形成對稱密鑰X + 證書中的公鑰s ，將對稱密鑰發給server端

注：如果有中間方修改了數據，用戶進行驗證時得到的散列值完全不同，該報文會被丟棄，只要中間方拿不到CA的私鑰 or 用戶使用的是合法的CA公鑰進行解密，注定了中間方無法對信息進行篡改

7. 后續雙方通過該對稱密鑰X進行通信。

補充：如何成為中間人？

假wifi or 假網站等