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

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

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

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

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

• 容易被竊聽：HTTP 傳輸的資料是明文。駭客很容易透過嗅探技術截獲報文，由於資料沒有加密，內容可以被駭客所理解。

  舉個例子：如果使用者輸入密碼取款，那麼駭客竊聽了此密碼後，就可以為所欲為了！

• 容易被篡改：駭客可以在截獲 HTTP 報文後，對報文進行修改，然後再傳送到目的地。

  舉個例子：如果使用者想要轉賬給家人，而駭客將收款人修改成了自己，將會造成使用者出現損失！

• 容易被偽造身份：駭客可以偽造 HTTP 報文，假裝自己是使用者真正想要訪問的網站，然後與使用者進行通訊。

  舉個例子：如果使用者想要訪問淘寶網站進行購物，而駭客冒充自己是淘寶網站，使用者就可能在此假淘寶網站上買東西，造成損失！

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

• 資料加密：HTTPS 傳輸的不再是明文，而是採用加密演算法傳輸密文，駭客即使截獲了報文，也無法理解內容！

• 完整性摘要：HTTPS 透過摘要演算法得到報文的一個摘要，如果駭客篡改了報文內容，那麼重新生成的摘要將發生變化，接收方校驗後就知道資料不再完整，被篡改了！

• 數字證書：HTTPS 透過數字證書來驗證通訊實體的身份，而駭客因為沒有相應的證書，一旦冒充其他網站將會被識破！

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

為了防止傳輸資料被駭客所竊聽，客戶端與伺服器之間需要對資料進行加解密處理。

傳送方使用加密演算法將明文加密為密文，而接收方使用相應的解密演算法將密文解密為明文。駭客只能看到密文，因而並不能獲取到任何有用資訊。如下圖所示：

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

• 對稱加密：指加密和解碼使用同一把金鑰，即圖中的金鑰 A 等於金鑰 B；

• 非對稱加密：指加密和解密使用不同的金鑰，即圖中的金鑰 A 不等於金鑰 B。

（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 採用混合加密方式，既採用對稱加密，也採用非對稱加密。

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

也就是說，用非對稱加密演算法傳輸金鑰，用對稱加密演算法傳輸實際資料。此金鑰一般稱為『會話金鑰』。

• 會話金鑰透過非對稱加密演算法傳輸，非常安全；

• 大量資料透過對稱加密演算法傳輸（多次），會話金鑰只需要傳一次，非常高效！    

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

摘要演算法也稱為雜湊演算法，其輸入為任意資料，輸出為固定長度的字串（稱為摘要）。主要特點如下：

• 不可逆，即無法透過輸出反推輸入。

• 相同的輸入必會產生相同的輸出。

• 不同的輸入大機率會產生不同的輸出。

• 無論輸入的資料有多長，輸出摘要的長度固定不變。

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

如果兩個輸入資料經過摘要演算法得到的輸出摘要一致，則稱為出現了雜湊碰撞。一個好的摘要演算法出現雜湊碰撞的機率非常低，而且非常難以透過輸出猜測輸入的內容！

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

為了防止傳輸資料被駭客所篡改，傳送方除了傳送實際資料外，還利用摘要演算法得到資料的一個摘要，並將此摘要一併傳送。

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

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

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

有了鑑別金鑰後，摘要演算法的輸入就不僅僅是傳輸資料了，而是傳輸資料和鑑別金鑰！駭客由於不知道鑑別金鑰，就無法再偽造輸入，篡改的摘要也就不正確了，從而保證了安全性！

資料和鑑別金鑰級聯後經過摘要演算法所生成的摘要有個專用名字，稱為報文鑑別碼，簡稱 MAC。

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

1. 用於從客戶端傳送到伺服器的資料的會話金鑰；

2. 用於從伺服器傳送到客戶端的資料的會話金鑰；

3. 用於從客戶端傳送到伺服器的資料的鑑別金鑰；

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）申請，而且是需要收費的！

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

• 伺服器（正規網站）首先生成一對公鑰和私鑰，然後將域名、申請者、公鑰（注意不是私鑰，私鑰是無論如何也不能洩露的）等資訊整合在一起，生成 .csr 檔案，並將此檔案發給認證中心 CA。

• CA 收到申請後，會透過各種手段驗證申請者的資訊，如無異常，則使用摘要演算法得到 .csr 中明文資訊的一個摘要，再用 CA 自己的私鑰對這個摘要進行加密，生成一串密文，密文也稱為數字簽名。數字證書即包含此數字簽名和 .csr 中明文資訊。CA 把這個證書返回給申請人。

• 為了防止中間人攻擊，客戶端要求伺服器傳送其證書，並進行驗證。

• 客戶端在驗證證書時，把證書裡的簽名與及明文資訊分別取出來，然後會用自身攜帶的 CA 機構的公鑰去解密簽名，得到摘要 1，再利用摘要演算法得到明文資訊的摘要 2，對比摘要 1 和摘要 2，如果一樣，說明證書是合法的，也就是證書裡的公鑰是正確的，否則說明證書不合法。    

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

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

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

• HTTPS 透過混合加密演算法解決 HTTP 傳輸資料容易被竊聽的問題，此過程需要協商會話金鑰。

• HTTPS 透過摘要演算法解決 HTTP 傳輸資料容易被篡改的問題，此過程需要協商鑑別金鑰。

• HTTPS 透過數字證書解決 HTTP 協議中身份容易被偽造的問題，此過程需要客戶端驗證伺服器的證書。

那麼 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. 客戶端支援的密碼套件列表，每個密碼套件包含：

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

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

3. 用於傳輸資料的對稱加密演算法，如 AES_128_GCM、AES_128_CBC；

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

5. 格式為：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 四次握手的過程。