---

一、HTTPS

HTTPS協議其實就是將HTTP協議中發送的報文和接收的報文經過加密后發送出去。
這就是HTTPS協議。

• 加密就是將一個原文經過一系列變換變成另一個密文。
• 解密就是將一個密文經過一系列變換變回原文。

二、HTTPS協議五種加密方案

1.只使用對稱加密

對稱加密，對稱加密就是通信雙方都持有同一個密鑰。
假如這個密鑰沒有被其他人知道的話，這樣通信雙方就會是安全的。

但是沒有假如，對稱密鑰也就是只持有一個公鑰，這個公鑰通過客戶端發送給服務器時，要經過網絡，極易被其他人獲取到，這樣雙方的通信就不安全了。

并且，如果是客戶端持有公鑰的話，每個客戶端對應發送一個公鑰給客戶端，服務器同時連接成千上萬個客戶端，這樣就需要保存和管理多份公鑰數據對象，這也是一個比較麻煩且耗時的問題。

所以理想的做法是，在進行通信前，就進行密鑰協商。

但是如果直接把密鑰明文傳輸, 那么黑客也就能獲得密鑰了，此時后續的加密操作就形同虛設了
因此密鑰的傳輸也必須加密傳輸

但是要想對密鑰進行對稱加密, 就仍然需要先協商確定一個 “密鑰的密鑰”. 這就成了 “先有雞還是先有蛋” 的問題了. 此時密鑰的傳輸再用對稱加密就行不通了

不過由于只有一個公鑰進行加密解密，所以速度非常快，算法不復雜，如果在安全的前提下，使用對稱加密是非常高效的。

2.只使用非對稱加密

非對稱密鑰是，持有一對密鑰，分別是公鑰和私鑰。
可以采用公鑰加密，私鑰解密；也可以私鑰加密，公鑰解密。

服務器與客戶端進行通信前，服務器發送公鑰給客戶端。
客戶端發送數據給服務器前，會進行加密，這樣就能保證客戶端到服務器單方面安全（其實也還有安全問題）

3.雙方都使用非對稱加密

客戶端和服務器各持有一對密鑰，分別是公鑰和私鑰。

雙方開始進行數據通信時，客戶端發送自己的公鑰C給服務器，服務器收到后，發送自己的公鑰S給客戶端。這樣通信兩端就持有對方的公鑰。

此時再進行數據通信時，使用對方的公鑰進行加密，雖然中間人也截取到雙方的公鑰，但是沒有私鑰，是無法解密的。這樣就保證了雙方的通信安全（真的嗎？)

看似安全了，這個方案仍然存在兩個問題:

1.不安全
2.效率低下

使用非對稱密鑰進行加密解密，會經過大量算法計算，就會比較耗時。

4.對稱加密+非對稱加密

服務器持有一對密鑰：公鑰S和私鑰S’
客戶端本地生成一個對稱密鑰C

服務端具有非對稱公鑰 S 和私鑰 S’

• 1.客戶端發起 https 請求，獲取服務端公鑰 S
• 2.客戶端在本地生成對稱密鑰 C, 通過公鑰 S 加密, 發送給服務器.
• 3.由于中間的網絡設備沒有私鑰, 即使截獲了數據, 也無法還原出內部的原文, 也就無法獲取到對稱密鑰(真的嗎？)
• 4.服務器通過私鑰 S’解密, 還原出客戶端發送的對稱密鑰 C. 并且使用這個對稱密鑰加密給客戶端返回的響應數據.
• 5.后續客戶端和服務器的通信都只用對稱加密即可. 由于該密鑰只有客戶端和服務器兩個主機知道, 其他主機/設備不知道密鑰即使截獲數據也沒有意義

這樣就大大提高了效率，因為只有一開始使用非對稱加密進行密鑰交換，后續都會使用對稱加密進行通信。

但是！

其實方案2，3，4都存在安全問題：中間人攻擊

中間人攻擊

比如方案4：

• 1.服務器自己持有一對密鑰S和S’，中間人自己也持有一對密鑰M和M’
• 2.客戶端發起HTTP請求時，服務器發送響應，將自己的公鑰S發給客戶端，中間人將服務器的公鑰S，替換成自己的公鑰M，繼續發給客戶端。
• 3.客戶端將自己本地生成的對稱密鑰C，通過服務端的公鑰加密后（客戶端當然不知道已經被換了），發送給服務端。
• 4.中間人使用自己的私鑰M’進行解密，獲取到了客戶端的對稱密鑰
• 5.將該對稱密鑰用曾經獲取到的服務器的公鑰S加密后，繼續將報文發給服務器，服務器此時通過自己的私鑰S’，也拿到了客戶端的對稱密鑰。
• 6.客戶端和服務器從此之后使用對稱密鑰加密通信。
• 7.中間人對整個過程了如指掌，想監聽，竊取和篡改數據都可以了。

如上的攻擊過程同樣對方案2，3有用。

問題的本質就出現在，客戶端無法確定收到含有公鑰的報文，就是服務器發過來的！！

理解數字簽名

1.將一份數據（比如10000字節），經過一些哈希函數算法計算后，得到一個散列值，這個散列值叫數據摘要（這個散列值是固定長度的）。
2.再用該散列值，拿簽名者的私鑰進行加密，得到數字簽名（比如50字節)。
3.拿原數據和簽名進行拼接（10050字節），就得到了帶有數字簽名的數據。

數字簽名存在的意義，就是驗證原始的明文數據是否被篡改過。
我們知道，用哈希算法形成的數據摘要，只要原始數據修改過1個比特位，其形成的數據摘要都差別非常大的。（幾乎不可能形成重復的數據摘要）

如何驗證數字簽名？

1.將原始的明文數據，進行同樣的哈希算法得到一個散列值。
2.再拿簽名者的公鑰，進行解密，得到散列值。
3.判斷兩者的散列值是否一樣，如果一樣，則數字簽名有效，即數據沒有被篡改過。

---

這里有很多疑問。
1.簽名者是誰？為什么要用他的簽名？我的簽名，中間人的簽名不行嗎？

如果采用中間人自己的私鑰對散列值加密，得到一個數字簽名，然后讓客戶端用中間人自己的公鑰
解密，得到相同的散列值，這樣是可以的。但問題是，客戶端不承認中間人的合法性！！！
在頒發數字簽名給服務器客戶端時，就已經內置式地通知客戶端，必須使用我給你的公鑰來對數字簽名解密，用其他任何人的公鑰解密都是無效的！！

因為世界上只有我一個人持有私鑰，意味著只有我一個人可以進行數字簽名！！
這是一種權力，誰持有大家都認可的公鑰，誰就可以簽名。

CA機構和證書

其實，CA機構就是上面數字簽名中的簽名者。

而證書的樣子如下：
證書并不是只包含一個服務器的公鑰，而是在證書中含有公鑰。

證書 = 用明文信息經過哈希算法生成數據摘要后再通過CA機構的私鑰加密生成的數字簽名 + 原始的明文信息。

服務端在使用 HTTPS 前，需要向 CA 機構申領一份數字證書，數字證書里含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務端公鑰的權威性

證書的申請過程：

1.服務器填寫資料，包括服務器自己的公鑰等信息，生成請求文件發給CA機構。
2.CA機構進行審核，審核通過后，通過數字簽名+服務器的明文信息形成證書發給申請者（服務器）
3.有客戶端建立HTTPS請求時，服務器發給客戶端的響應中就會攜帶證書。
4.客戶端提取證書的數字簽名拿內置的CA機構的公鑰對簽名解密，在對證書的明文信息進行哈希算法加密后形成的兩個散列值對比驗證證書的合法性。

只要合法了，就能進行對稱加密通信了！！

---

5. 對稱加密+非對稱加密+證書認證

到這里，其實已經知道了方案5的具體實現流程了。

客戶端進行認證
當客戶端獲取到這個證書之后, 會對證書進行校驗(防止證書是偽造的).
? 判定證書的有效期是否過期
? 判定證書的發布機構是否受信任(操作系統中已內置的受信任的證書發布機構).
? 驗證證書是否被篡改: 從系統中拿到該證書發布機構的公鑰, 對簽名解密, 得到一個 hash 值(稱為數據摘要), 設為 hash1. 然后計算整個證書的 hash 值, 設為 hash2. 對比 hash1 和 hash2 是否相等. 如果相等, 則說明證書是沒有被篡改過的。

中間人篡改證書？

中間人如果篡改證書中的公鑰，改成自己的，客戶端在進行證書認證時，對明文信息進行哈希得到的散列值和對數字簽名進行解密（用CA機構給的公鑰）得到的散列值就不一樣，就認定證書不合法，此時客戶端就不會再對服務器進行通信了！

中間人調包整個證書？

中間人沒有CA機構的私鑰，無法用哈希后的散列值進行私鑰加密，就無法制作假證書。
想要調包整個證書，只能去申請真的證書來調包服務器的證書。
這樣做理論上可行，但是，證書中除了有公鑰信息，還有域名信息等。
域名信息也是具有唯一性的，客戶端一檢查發現域名不對，也會停止向服務器發送信息。

更何況，中間人既然是中間人，他也不會傻到泄露自己的信息去申請真證書吧。

常見問題

1.為什么用哈希算法形成的摘要在網絡中傳輸時一定要加密形成簽名？

• 1）通過CA機構的私鑰加密形成簽名才能保證證書合法性，因為中間人無法調包證書，也無法篡改證書。
• 2）如果不加密，直接傳輸摘要，那中間人很容易就把摘要替換調包，（可以直接替換內容，然后通過MD5等算法生成一樣的摘要）這樣就不具備安全性了。

2.為什么明文數據不直接通過CA機構的私鑰加密形成簽名，而是要先通過哈希形成摘要？

• 這樣是為了縮小形成簽名后的長度，加快形成簽名的時間和對簽名驗證的時間，提高效率。

總結

HTTPS 工作過程中涉及到的密鑰有三組：

• 第一組(非對稱加密)：用于校驗證書是否被篡改。服務器持有CA證書，客戶端持有CA機構的公鑰（操作系統包含了可信任的CA認證機構并持有對應的公鑰），客戶端會對服務器發來的CA證書進行認證，保證證書合法性，其實就是讓客戶端信任服務器是合法的，同時也保證了服務器的公鑰是合法的。
• 第二組（非對稱加密）：用于協商生成的對稱密鑰。客戶端通過信任后的服務器公鑰加密，將客戶端本地生成的對稱密鑰加密后傳輸給服務器，服務器用自己的私鑰解密，得到對稱密鑰。
• 第三組（對稱加密）：雙方都持有對稱密鑰，此后使用對稱加密進行通信。

第一組對稱密鑰（CA的公鑰和私鑰）是為了讓客戶端拿到第二組對稱密鑰的公鑰（服務器的）
第二組對稱密鑰（服務器的公鑰和私鑰）是為了安全拿到客戶端傳輸過來的對稱密鑰。