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

1. 不安全的 HTTP

近些年來，越來越多的網(wǎng)站使用 HTTPS 協(xié)議進行數(shù)據(jù)傳輸，原因在于 HTTPS 相較于 HTTP 能夠提供更加安全的服務(wù)。

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

為什么 HTTP 協(xié)議不安全呢？主要表現(xiàn)在以下三個方面：

容易被竊聽：HTTP 傳輸?shù)臄?shù)據(jù)是明文。黑客很容易通過嗅探技術(shù)截獲報文，由于數(shù)據(jù)沒有加密，內(nèi)容可以被黑客所理解。

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

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

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

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

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

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

數(shù)據(jù)加密：HTTPS 傳輸?shù)牟辉偈?strong>明文，而是采用加密算法傳輸密文，黑客即使截獲了報文，也無法理解內(nèi)容！

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

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

2. 加密算法

加密算法用于解決 HTTP 傳輸數(shù)據(jù)容易被竊聽的問題。

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

發(fā)送方使用加密算法將明文加密為密文，而接收方使用相應(yīng)的解密算法將密文解密為明文。黑客只能看到密文，因而并不能獲取到任何有用信息。如下圖所示：

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

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

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

（1）對稱加密

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

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

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

這種方式的缺點在于：每個字母經(jīng)過加密后只有唯一的密文表示，如果黑客收集了很多數(shù)據(jù)后進行統(tǒng)計分析，很可能就破解了加密手段。

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

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

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

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

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

計算機網(wǎng)絡(luò)中常用的對稱加密算法有：DES、3DES、AES 等，都屬于分組加密算法。

（2）非對稱加密

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

如果用公鑰加密，則只能用私鑰解密，此時公鑰是不能解密的。

如果用私鑰加密，則只能用公鑰解密，此時私鑰是不能解密的。

公鑰是對外公開的，任何人都能夠得到；私鑰只有自己知道，不能泄露。

為什么有了對稱加密后還會出現(xiàn)非對稱加密呢？

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

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

計算機網(wǎng)絡(luò)中常用的非對稱加密算法有：RSA、 ECDHE 等。

相較于對稱加密，非對稱加密算法更加復雜難懂，數(shù)學推理較多，如果對具體算法感興趣的，可以看一下阮一峰的兩篇文章：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）混合加密

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

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

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

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

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

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

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

3. 摘要算法

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

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

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

相同的輸入必會產(chǎn)生相同的輸出。

不同的輸入大概率會產(chǎn)生不同的輸出。

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

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

如果兩個輸入數(shù)據(jù)經(jīng)過摘要算法得到的輸出摘要一致，則稱為出現(xiàn)了哈希碰撞。一個好的摘要算法出現(xiàn)哈希碰撞的概率非常低，而且非常難以通過輸出猜測輸入的內(nèi)容！

計算機網(wǎng)絡(luò)中常用的摘要算法有：MD5、SHA-1、SHA-256 等。

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

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

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

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

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

數(shù)據(jù)和鑒別密鑰級聯(lián)后經(jīng)過摘要算法所生成的摘要有個專用名字，稱為報文鑒別碼，簡稱 MAC。

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

用于從客戶端發(fā)送到服務(wù)器的數(shù)據(jù)的會話密鑰；

用于從服務(wù)器發(fā)送到客戶端的數(shù)據(jù)的會話密鑰；

用于從客戶端發(fā)送到服務(wù)器的數(shù)據(jù)的鑒別密鑰；

用于從服務(wù)器發(fā)送到客戶端的數(shù)據(jù)的鑒別密鑰。

4. 數(shù)字證書

數(shù)字證書用于解決 HTTP 協(xié)議中身份容易被偽造的問題。

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

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

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

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

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

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

客戶端使用會話密鑰1對數(shù)據(jù)進行加密，并發(fā)送至中間人。

中間人使用會話密鑰1對數(shù)據(jù)進行解密，得到明文數(shù)據(jù)?。▽崿F(xiàn)了竊聽）

中間人使用會話密鑰2對數(shù)據(jù)（可能是篡改的）進行加密，并發(fā)送至正規(guī)網(wǎng)站。

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

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

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

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

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

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

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

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

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

Chrome 瀏覽器一旦發(fā)現(xiàn)一個網(wǎng)站數(shù)字證書無效，就會生成如下界面進行提示，如果用戶強制訪問，則存在一定的風險。

5. SSL/TLS 握手

根據(jù)前面所述，進行一下小結(jié)：

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

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

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

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

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

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

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

第一次握手

客戶端向服務(wù)器發(fā)起加密通信請求 ，內(nèi)容主要包括：

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

客戶端生產(chǎn)的隨機數(shù) 1，用于后續(xù)生成會話密鑰和鑒別密鑰。

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

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

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

用于傳輸數(shù)據(jù)的對稱加密算法，如 AES_128_GCM、AES_128_CBC；

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

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

第二次握手

服務(wù)器收到客戶端加密通信請求后，向客戶端發(fā)出響應(yīng)，內(nèi)容主要包括：

確認的 SSL/ TLS 協(xié)議版本，如果雙方支持的版本不同，則關(guān)閉加密通信。

服務(wù)器生產(chǎn)的隨機數(shù) 2，用于后續(xù)生成會話密鑰和鑒別密鑰。

確認的密碼套件，如 TLS_RSA_WITH_AES128_CBC_SHA。

服務(wù)器的數(shù)字證書。

第三次握手

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

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

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

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

客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。客戶端會生成所有握手報文數(shù)據(jù)的摘要，并用會話密鑰加密后發(fā)送給服務(wù)器，用來供服務(wù)端校驗。

第四次握手

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

之后進行第四次握手，內(nèi)容主要包括：

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

服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。服務(wù)器會生成所有握手報文數(shù)據(jù)的摘要，并用會話密鑰加密后發(fā)送給客戶端，用來供客戶端校驗。

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

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

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

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

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

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

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

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

編輯：黃飛

?