20 張圖帶你全面瞭解 HTTPS 協議，再也不怕面試問到了！

本文詳細介紹了 HTTPS 相較於 HTTP 更安全的原因，包括對稱加密、非對稱加密、完整性摘要、數字證書以及 SSL/TLS 握手等內容，圖文並茂、理論與實戰結合、建議收藏！

1. 不安全的 HTTP

近些年來，越來越多的網站使用 HTTPS 協議進行數據傳輸，原因在於 HTTPS 相較於 HTTP 能夠提供更加安全的服務。

很多瀏覽器對於使用 HTTP 協議的網站會加上『警告』的標誌表示數據傳輸不安全，而對於使用 HTTPS 協議的網站會加上一把『鎖』標誌表示數據傳輸安全。

爲什麼 HTTP 協議不安全呢？主要表現在以下三個方面：

HTTPS 是如何解決以上安全性問題的呢？主要方法如下所示：

2. 加密算法

加密算法用於解決 HTTP 傳輸數據容易被竊聽的問題。

爲了防止傳輸數據被黑客所竊聽，客戶端與服務器之間需要對數據進行加解密處理。

發送方使用加密算法將明文加密爲密文，而接收方使用相應的解密算法將密文解密爲明文。黑客只能看到密文，因而並不能獲取到任何有用信息。如下圖所示：

一般來說，加密算法分爲兩大類，對稱加密和非對稱加密。

（1）對稱加密

對稱加密算法中加密和解密的鑰匙是同一把，稱之爲密鑰。

凱撒密碼是一種較爲簡單的對稱加密算法，可用於對英語文本進行加解密。其主要思想是：將明文中的每個字母按照字母表所在位置右移 K 位，得到密文（允許迴繞）。

舉個例子，設 K = 2，那麼明文中的字母 "a" 用字母 "c" 代替，字母 "z" 用 字母 "b" 代替。此時 K = 2 就是對稱加密算法中的密鑰。

這種方式的缺點在於：每個字母經過加密後只有唯一的密文表示，如果黑客收集了很多數據後進行統計分析，很可能就破解了加密手段。

更好的方式是採用多個凱撒密碼 K 輪詢進行加密，比如位置爲奇數的字母採用密鑰 K = 2 加密，位置爲偶數的字母採用密鑰 K = 3 加密。

然而凱撒密碼只能加密英文文本，若想要加密所有字符，可以採用分組加密的方式。

我們知道任何數據在計算機中實際存儲的是 0/1 比特的組合。分組加密的主要思想是：將要加密的報文處理爲 K 比特的分組，每個分組通過一對一的映射表進行加密。

舉個例子，設 K = 3，映射表如下圖，那麼報文 010110001111 將會被加密爲 101000111001。此時 K=3 以及映射表就是對稱加密算法中的密鑰。

與前面採用多個凱撒密碼 K 作爲密鑰的方式一樣，爲了增加破解的難度，一種更好的方式是採用多個映射表，輪詢對數據進行加密。

計算機網絡中常用的對稱加密算法有：DES、3DES、AES 等，都屬於分組加密算法。

（2）非對稱加密

非對稱加密算法中加密和解密的鑰匙不同，分別稱爲公鑰和私鑰。其特點在於：

爲什麼有了對稱加密後還會出現非對稱加密呢？

原因在於對稱加密的前提是通信雙方需要商量出一個密鑰，而商量密鑰的時候傳輸的是明文，如果此密鑰被黑客所截獲，即使後面的報文進行了加密，黑客也可以通過此密鑰進行解密！

非對稱加密的一個特點是：公鑰加密，只有私鑰可以解密。那麼就無需像對稱加密那樣提前協商好密鑰。通信雙方可以直接將自己的公鑰發送給另一方，這個公鑰即使黑客知道也無所謂，當一方用此公鑰加密後，即使黑客截獲了報文，也無法用公鑰解密，只有擁有私鑰的另一方纔能解密成功！

計算機網絡中常用的非對稱加密算法有：RSA、 ECDHE 等。

相較於對稱加密，非對稱加密算法更加複雜難懂，數學推理較多，如果對具體算法感興趣的，可以看一下阮一峯的兩篇文章：RSA 算法原理（一）和 RSA 算法原理（二）。

https://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html

http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

（3）混合加密

前面提到，對稱加密算法需要提前協商出密鑰，而協商的過程用的是明文（因爲還沒有密鑰），如果黑客截獲了明文密鑰，那麼之後即使加密了，黑客也可以用密鑰進行解密，此時就無安全性可言了！

非對稱加密算法解決了此問題，但是其存在大量的指數運算，加密速度非常慢！而對稱加密算法的加密速度非常快，一般是非對稱加密算法的 100-10000 倍！

那能不能將二者綜合起來，使得數據傳輸不僅安全且高效呢？答案是肯定的！HTTPS 採用混合加密方式，既採用對稱加密，也採用非對稱加密。

對稱加密算法的弱點在於協商密鑰的過程採用明文不安全，存在密鑰泄漏的可能，那麼我們是不是可以不採用明文，而是採用非對稱加密算法來協商此密鑰，之後傳輸數據時再採用對稱加密算法進行加密。

也就是說，用非對稱加密算法傳輸密鑰，用對稱加密算法傳輸實際數據。 此密鑰一般稱爲『會話密鑰』。

3. 摘要算法

摘要算法用於解決 HTTP 傳輸數據容易被篡改的問題。

摘要算法也稱爲哈希算法，其輸入爲任意數據，輸出爲固定長度的字符串（稱爲摘要）。主要特點如下：

舉個例子：如果將數據的比特流每 8 個比特進行分組（不足的補零），然後將所有分組進行按位異或運算，那麼生成的結果就可以稱爲摘要，此算法就是一種簡單的摘要算法。

如果兩個輸入數據經過摘要算法得到的輸出摘要一致，則稱爲出現了哈希碰撞。一個好的摘要算法出現哈希碰撞的概率非常低，而且非常難以通過輸出猜測輸入的內容！

計算機網絡中常用的摘要算法有：MD5、SHA-1、SHA-256 等。

爲了防止傳輸數據被黑客所篡改，發送方除了發送實際數據外，還利用摘要算法得到數據的一個摘要，並將此摘要一併發送。

接收方收到數據後，利用同樣的摘要算法再次得到數據的摘要，並將其與發送方發送的摘要進行比對校驗，如果二者不一致，則說明數據被篡改了，反之則沒有。

小夥伴們很容易看出來上述方式存在明顯缺陷，如果黑客不僅篡改了數據，而且同時篡改了摘要，接收方不就無法判斷數據是否被篡改了嗎？

爲了防止這種情況的發生，發送方與接收方必須有一個只有二者知道的，而黑客不能知道的東西，比如對稱加密的會話密鑰。不過爲了提升安全性，此時一般不使用會話密鑰，而是使用一個新的密鑰，稱之爲鑑別密鑰，這個密鑰的獲取同會話密鑰。

有了鑑別密鑰後，摘要算法的輸入就不僅僅是傳輸數據了，而是傳輸數據和鑑別密鑰！黑客由於不知道鑑別密鑰，就無法再僞造輸入，篡改的摘要也就不正確了，從而保證了安全性！

數據和鑑別密鑰級聯後經過摘要算法所生成的摘要有個專用名字，稱爲報文鑑別碼，簡稱 MAC。

爲了進一步提升安全性，實際上客戶端和服務器將使用不同的會話密鑰和鑑別密鑰，也就是一共需要四個密鑰：

  1. 用於從客戶端發送到服務器的數據的會話密鑰；

  2. 用於從服務器發送到客戶端的數據的會話密鑰；

  3. 用於從客戶端發送到服務器的數據的鑑別密鑰；

  4. 用於從服務器發送到客戶端的數據的鑑別密鑰。

4. 數字證書

數字證書用於解決 HTTP 協議中身份容易被僞造的問題。

前面提到 HTTPS 採用非對稱加密算法傳輸會話密鑰。一般是服務器將公鑰對外公佈，客戶端利用此公鑰加密會話密鑰，然後服務器通過私鑰解密得到會話密鑰，此時雙方即協商好了用於對稱加密傳輸數據的密鑰。

但是萬一服務器的公鑰是被黑客僞造的呢？比如經典的『中間人攻擊』問題：

  1. 客戶端發送的請求被中間人（黑客）劫持（如使用 DNS 劫持），所有請求均發送至中間人。

  2. 中間人假裝自己是正規網站（服務器），向客戶端返回自己的公鑰 2 ，並索要正規網站的公鑰 1。

  3. 客戶端使用中間人的公鑰 2 加密會話密鑰1，併發送至中間人。

  4. 中間人使用自己的私鑰 2 解密得到會話密鑰1，同時假裝自己是客戶端，使用正規網站的公鑰 1 加密會話密鑰2（可以與會話密鑰 1 相同）併發送至正規網站。

  5. 客戶端使用會話密鑰1對數據進行加密，併發送至中間人。

  6. 中間人使用會話密鑰1對數據進行解密，得到明文數據！（實現了竊聽）

  7. 中間人使用會話密鑰2對數據（可能是篡改的）進行加密，併發送至正規網站。

此時，客戶端與服務器的通信再無安全性可言！中間人不僅能夠竊聽到消息內容，還能夠進行篡改！

客戶端如何知道自己所擁有的公鑰是來自於正規網站而不是中間人呢？這時候就需要數字證書了！

數字證書的概念就像是我們的身份證一樣，專門用於驗證通信實體的身份。咱們的身份證是去派出所申請的，而數字證書則需要向認證中心（Certification Authority，CA）申請，而且是需要收費的！

通過數字證書解決中間人攻擊的具體過程爲：

瀏覽器如何得到認證中心的公鑰呢？萬一此公鑰是被僞造的呢？爲了防止套娃，實際電腦操作系統中會內置這些認證中心的公鑰！因而無需擔心認證中心公鑰被僞造的問題。

Chrome 瀏覽器一旦發現一個網站數字證書無效，就會生成如下界面進行提示，如果用戶強制訪問，則存在一定的風險。

5. SSL/TLS 握手

根據前面所述，進行一下小結：

那麼 HTTPS 具體是怎麼做的呢？通信雙方在什麼時候協商會話密鑰和鑑別密鑰、什麼時候驗證證書合法性的呢？答案是 SSL/TLS 協議握手的時候。

HTTPS 比 HTTP 多的那個『S』就是指 SSL/TLS 協議。

在 HTTPS 協議中，當客戶端與服務器通過三次握手建立 TCP 連接之後，並不會直接傳輸數據，而是先會經過一個 SSL/TLS 握手的過程，用於協商會話密鑰、鑑別密鑰以及驗證證書等，之後就可以安全傳輸數據了！

下面通過 Wireshark 抓包，具體講一下 SSL/TLS 1.2 四次握手的過程。

第一次握手 

客戶端向服務器發起加密通信請求 ，內容主要包括：

  1. 客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本。

  2. 客戶端生產的隨機數 1，用於後續生成會話密鑰和鑑別密鑰。

  3. 客戶端支持的密碼套件列表，每個密碼套件包含：

  4. 用於傳輸會話密鑰的非對稱加密算法，如 ECDHE、RSA；

  5. 用於驗證數字證書的非對稱加密算法，如 ECDHE、RSA；

  6. 用於傳輸數據的對稱加密算法，如 AES_128_GCM、AES_128_CBC；

  7. 用於驗證報文完整性的摘要算法，如 SHA256、SHA384；

  8. 格式爲：TLS_非對稱加密算法_非對稱加密算法_對稱加密算法_摘要算法，如果兩個非對稱加密算法一致，可省略不寫。

第二次握手 

服務器收到客戶端加密通信請求後，向客戶端發出響應，內容主要包括：

  1. 確認的 SSL/ TLS 協議版本，如果雙方支持的版本不同，則關閉加密通信。

  2. 服務器生產的隨機數 2，用於後續生成會話密鑰和鑑別密鑰。

  3. 確認的密碼套件，如 TLS_RSA_WITH_AES128_CBC_SHA。

  4. 服務器的數字證書。

第三次握手 

客戶端收到服務器的迴應之後，會驗證其數字證書是否合法（驗證方法在數字證書小節中有說明），如果證書合法，則進行第三次握手，內容主要包括：

  1. 客戶端生產的另一個隨機數 3（稱爲前主密鑰，Pre-Master Secret，簡寫爲 PMS），此隨機數會被服務器公鑰加密。

    客戶端根據隨機數 1、隨機數 2 以及前主密鑰計算出主密鑰（Master Secret，MS），接着將主密鑰切片得到兩個會話密鑰和兩個鑑別密鑰。

  2. 加密通信算法改變通知，表示之後數據都將用會話密鑰進行加密。

  3. 客戶端握手結束通知，表示客戶端的握手階段已經結束。客戶端會生成所有握手報文數據的摘要，並用會話密鑰加密後發送給服務器，用來供服務端校驗。

第四次握手 

服務器收到客戶端的消息後，利用自己的私鑰解密出前主密鑰，並根據隨機數 1、隨機數 2 以及前主密鑰計算出主密鑰，接着將主密鑰切片得到兩個會話密鑰和兩個鑑別密鑰。

之後進行第四次握手，內容主要包括：

  1. 加密通信算法改變通知，表示之後數據都將用會話密鑰進行加密。

  2. 服務器握手結束通知，表示服務器的握手階段已經結束。服務器會生成所有握手報文數據的摘要，並用會話密鑰加密後發送給客戶端，用來供客戶端校驗。

至此，整個 SSL/TLS 的握手階段全部結束！

爲什麼第三、第四次握手要發送所有握手報文的摘要呢？

主要原因是防止握手信息被篡改。比如客戶端支持的密碼套件列表中，有些加密算法較弱，有些加密算法較強，而此密碼套件是明文傳輸的，萬一黑客將此密碼套件列表進行了修改，只留下一些安全性較低的加密算法，那麼服務器就只能從這些安全性較低的加密算法中選擇，安全性大大降低。因此需要通過發送摘要的形式防止握手信息被篡改。

爲什麼不直接發送一個主密鑰，而是用兩個隨機數加一個前主密鑰重新生成一個主密鑰呢？

主要原因是防止連接重放。如果沒有前面兩個隨機數，僅僅由客戶端生成一個主密鑰，並通過服務器公鑰加密發送給服務器。那麼黑客在嗅探了服務器與客戶端之間的所有報文後，可以再次冒充客戶端向服務器發送相同的報文（雖然黑客不知道內容是什麼），因爲報文信息都是之前客戶端和服務器驗證過的，因此服務器會認爲是客戶端與其通信，導致又一次連接。

假如服務器是一個購物網站，那麼此連接重放會導致客戶端再一次下單，造成損失。

而如果有了前兩個隨機數，即使黑客冒充客戶端想要連接重放，然而由於隨機數不同，生成的密鑰則不同，黑客重新發送的內容將失效（服務器不能理解、完整性摘要也不對）。

最後，用一張圖總結 TLS 四次握手的過程。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4qSc0emO-CeNDaJlgSjbRA

猜你喜歡