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

1. 不安全的 HTTP

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

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

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

容易被竊聽：HTTP 傳輸的數據是明文。黑客很容易通過嗅探技術截獲報文，由于數據沒有加密，內容可以被黑客所理解。

舉個例子：如果用戶輸入密碼取款，那么黑客竊聽了此密碼后，就可以為所欲為了！

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

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

容易被偽造身份：黑客可以偽造 HTTP 報文，假裝自己是用戶真正想要訪問的網站，然后與用戶進行通信。

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

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

數據加密：HTTPS 傳輸的不再是明文，而是采用加密算法傳輸密文，黑客即使截獲了報文，也無法理解內容！

完整性摘要：HTTPS 通過摘要算法得到報文的一個摘要，如果黑客篡改了報文內容，那么重新生成的摘要將發生變化，接收方校驗后就知道數據不再完整，被篡改了！

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

2. 加密算法

加密算法用于解決 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 采用混合加密方式，既采用對稱加密，也采用非對稱加密。

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

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

會話密鑰通過非對稱加密算法傳輸，非常安全；

大量數據通過對稱加密算法傳輸（多次），會話密鑰只需要傳一次，非常高效！????

3. 摘要算法

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

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

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

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

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

無論輸入的數據有多長，輸出摘要的長度固定不變。

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

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

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

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

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

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

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

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

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

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

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

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

用于從客戶端發送到服務器的數據的鑒別密鑰；

用于從服務器發送到客戶端的數據的鑒別密鑰。

4. 數字證書

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務器（正規網站）首先生成一對公鑰和私鑰，然后將域名、申請者、公鑰（注意不是私鑰，私鑰是無論如何也不能泄露的）等信息整合在一起，生成 .csr 文件，并將此文件發給認證中心 CA。

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

為了防止中間人攻擊，客戶端要求服務器發送其證書，并進行驗證。

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

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

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

5. SSL/TLS 握手

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

HTTPS 通過混合加密算法解決 HTTP 傳輸數據容易被竊聽的問題，此過程需要協商會話密鑰。

HTTPS 通過摘要算法解決 HTTP 傳輸數據容易被篡改的問題，此過程需要協商鑒別密鑰。

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

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

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

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

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

第一次握手

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

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

客戶端生產的隨機數 1，用于后續生成會話密鑰和鑒別密鑰。

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

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

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

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

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

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

第二次握手

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

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

服務器生產的隨機數 2，用于后續生成會話密鑰和鑒別密鑰。

確認的密碼套件，如 TLS_RSA_WITH_AES128_CBC_SHA。

服務器的數字證書。

第三次握手

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

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

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

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

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

第四次握手

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

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

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

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

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

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

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

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

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

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

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

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

編輯：黃飛

?