如何簡單的從宏觀上理解HTTP/HTTPS的加密過程？

本文主要是本身在學網絡這一塊的一些我的理解，主要是宏觀上的一些解釋，旨在對整個過程有個大概的瞭解。 咱們知道HTTP都是明文傳輸的，因此通訊信息容易被攔截，所以出現了不少手段來保證信息的安全。

HTTP時代的加密

名詞解釋

對稱加密： 加密和解密都是用同一個祕鑰。速度快。

非對稱加密： 分公鑰和私鑰。公鑰是公開的，私鑰只有本身知道。公鑰加密的只能用私鑰解密，私鑰加密只能用公鑰解密。因此叫非對稱加密。

加密和簽名： 借用知乎的一個回答。

加密： 既然是加密，那確定是不但願別人知道個人消息，因此只有我才能解密，所以是公鑰加密，私鑰解密。

簽名： 既然是簽名，那確定不但願別人冒充我，因此只有我才能簽名，所以是私鑰加密，公鑰解密。

加密方法：

• 使用對稱加密，須要傳輸私鑰。存在問題：私鑰被攔截。
• 使用非對稱加密，須要傳輸公鑰。 存在問題： 1. 公鑰被攔截；2.加密速度太慢

針對加密速度： 使用非對稱傳輸對稱加密的祕鑰，而後用對稱加密來通訊。

主要流程以下：

1. 獲取雙方的公鑰
2. 使用公鑰傳輸私鑰
3. 使用私鑰進行對稱加密，進行通訊
複製代碼

針對公鑰被攔截：引入CA和數字證書。

CA至關於現實中的公證處，簡單理解就是CA頒發給服務端一個數字證書，而瀏覽器能夠鑑別這個證書是否是真的。能夠從數字證書中得到服務端的公鑰。

首先服務端經過CA生成數字證書（含數字簽名）：

服務端將數字證書傳遞給客戶端，客戶端驗證消息是否被篡改的過程：

經過上述過程，便安全獲取了服務端的公鑰。完成了步驟1. 整個過程以下：

HTTPS時代的加密

TLS握手：

使用RSA加密方式：

1. 客戶端給服務端傳遞隨機數X
2. 服務端給客戶端傳遞一個隨機數Y和數字證書
3. 客戶端根據數字證書獲得服務端公鑰，並用公鑰加密傳遞給服務端Z。
4. 服務端解密得到Z.
5. 服務端和客戶端都有三個參數X,Y,Z。根據同一個加密算法F(X,Y,Z)得到對稱加密的祕鑰key。

但X,Y,Z均爲明文傳輸，X,Y,Z被hacker拿到後，他也能夠生成一樣對稱加密的祕鑰key。

目前主流的是ECDHE加密方式：

1. 客戶端給服務端傳遞隨機數X
2. 服務端給客戶端傳遞一個隨機數Y
3. 服務端繼續給客戶端傳遞服務端參數A。
4. 客戶端傳遞客戶端參數B給服務端，以上均爲明文傳輸。
5. 此時客戶端和服務端都有四個參數X,Y,A,B。經過算法生成一個參數Z, 在由X,Y,Z 生成對稱加密的祕鑰key。

以前的疑惑是既然X,Y,A,B均爲明文傳輸，hacker攔截後也同樣能夠經過算法生成key啊，不就不安全了嗎？

這就要講到DH算法了，DH，DHE，ECDHE算法能夠理解爲不斷的優化，本質上仍是同樣的。爲何這個過程是安全的，關鍵就在於A,B。

DH算法是服務端根據參數a, 生成A = F(a). 客戶端根據參數b，生成B = F(b)。並且即便hacker知道A，也知道算法F(),可是沒法推算出a的值，同理b的值也沒法獲取。

該算法存在如下關係, 生成Z：

Z = A * b = B * a 。

明文傳遞有X, Y, A, B.

由於hacker沒法獲取a,b的值，因此生成的Z是安全的，所以經過X,Y,Z生成的對稱祕鑰也是安全的。

附上詳細的RSA過程：

詳細的ECDHE

參考文章

• 一個故事講完https
• 徹底吃透 TLS/SSL
• TLS握手協議分析與理解——某HTTPS請求流量包分析