一篇漫畫故事帶你理解透HTTPS（下）

摘要：5 小紅收到信息就用自己的私鑰進行解密，然後取出字符a，隨後小紅將內容 “同意傳紙條” 用字符a作爲密鑰進行對稱加密，得到密文後寫入紙條中。1、服務端配置正確了對應的安全證書 2、客戶端發送請求到服務端 3、服務端返回公鑰和證書到客戶端 4、客戶端接收後會驗證證書的安全性，如果通過則會隨機生成一個隨機數，用公鑰對其加密，發送到服務端 5、服務端接受到這個加密後的隨機數後會用私鑰對其解密得到真正的隨機數，隨後用這個隨機數當做密鑰對需要發送的數據進行對稱加密 6、客戶端在接收到加密後的數據使用密鑰（即生成的隨機值）對數據進行解密並且解析數據呈現結果給客戶 7、SSL加密建立。

上下集知識點總結：

前情提要：

蝙蝠紀元，疫情之下。二丫欲訪問京東購物，不料彈出安全提示，遂找二毛一探究竟。二毛一頓排查後，開始用通俗易懂的語言深入淺出的向二丫解釋 HTTP作用及優缺點、HTTPS的功能作用......

未看過上集的，可進入傳送門：

【故事】跟零計算機基礎的房東女兒講了一下午的中間人劫持京東事件後，她感激涕零，決定給我免除房租（上）

二丫掛掉電話後，對二毛邪魅一笑...

開始之前，我們先了解一些前置技術。

前置技術

1 對稱加密

定義：一種加密算法，只有一個密鑰，這個密鑰既可以用來加密數據，又可以用來解密數據。

優點：加解密速度快。

缺點：由於只有一個密鑰，應用場景不廣泛。

2 非對稱加密

定義：也是一種加密算法，有兩個密鑰，一個稱爲公鑰，另一個稱爲私鑰。其中公鑰可以廣而告之，私鑰需要自己妥善保存。公鑰可以加密數據，然後用私鑰解密；反過來，私鑰也可以加密數據，用公鑰來解密。

優點：由於公鑰和私鑰可以互相加解密，應用場景廣泛。

缺點：加解密速度較慢。

3 消息摘要：

定義：通過哈希函數，將任意長度的消息變成固定長度的短消息，且一個固定的內容無論經過多少次哈希得到的結果仍然是固定不變的，稱爲消息摘要。

應用場景：可將長消息縮短，加密處理起來更快。

4 數字證書：

定義：由 CA （一個權威的認證機構）頒發的一種證書，裏面含有可以標識你身份的信息，類似於我們的身份證。

注：證書是必須由服務端主動向CA申請的。服務端（假設爲網站）提供自己的域名等信息，接着CA會使用它們的私鑰對內容進行加密，然後作爲數字證書返回給服務端。

應用場景：

身份證明。由於CA是權威的，他們的私鑰會嚴格保存，公鑰會廣爲公開，所以一旦服務端網站出示了數字證書後，我們就可以依據頒發證書的CA，找到對應的公鑰，然後解密數字證書得到裏面的域名信息，並比對當前訪問的域名是否跟得到的域名一致，以此判斷真假。

5 數字簽名：

定義：只有信息的發送者才能生成的、別人無法僞造的一段字符串。

主要有兩個步驟生成：

首先對要發送的內容進行 消息摘要 得到短字符串。
發送者再使用 自己的私鑰 對該短字符串進行加密，就得到了 數字簽名 。（當然也可以對整個信息做數字簽名，但是經過消息摘要處理的信息會更少，加密更快。）

應用場景：

完整性保護 ：只要我們使用發送者的公鑰解密數字簽名，得到原摘要內容，再跟我們自己進行消息摘要的內容進行對比，就能判斷，若一致，則說明信息內容沒篡改破壞過。
不可抵賴性 ：由於發送者的私鑰只有發送者自己知道，所以只要信息比對一致，就能證明這信息是該發送方寫的。

看到這裏，讀者可能有點懵，那 數字簽名跟數字證書有什麼不同？

數字簽名一般是用戶用 自己的私鑰 加密摘要生成的，目的是爲了數據完整性保護和不可抵賴性。
數字證書是使用 CA的私鑰 加密你的信息形成的，目的是證明你的身份。

HTTPS的技術實現

在上集的例子中，小明給小紅傳紙條，但是小明的明文通信可能會被第四排同學 竊聽、篡改、破壞、僞裝 ，而對應的解決方法就是使得通信規則能有這三個功能： 加密數據、數據完整性保護、身份驗證 。

那該如何使得通信規則有這三個功能？小明在研究了前置技術的內容後，受到啓發，決定這樣幹：

（這裏假設學校有個大隊長（即CA）能夠爲學生信息做公證，即頒發數字證書，小明小紅都已經申請了自己的數字證書。數字證書中包含 自己的姓名、自己的公鑰 等信息）

1 在開始傳對話內容前，小明就先傳紙條請求小紅的數字證書，請求時也把自己的數字證書傳過去。

2 小紅收到信息後，就用大隊長的公鑰解密得到信息，得知是小明請求與她傳紙條，於是她含羞的把自己的數字證書回傳了過去。

3 小明得到返回的數字證書後，也用 大隊長的公鑰 解密得到信息（信息含有小紅姓名和小紅公鑰），比對姓名信息看是否爲小紅。如果不是小紅，則不通信，如果是，進入下一步。

4 小明隨機生成一串字符a，然後拿出 小紅的公鑰 ，並用該公鑰加密這串字符a，返回給小紅。

5 小紅收到信息就用自己的私鑰進行解密，然後取出字符a，隨後小紅將內容 “同意傳紙條” 用字符a作爲密鑰進行 對稱加密 ，得到密文後寫入紙條中。另外，小紅也對內容 “同意傳紙條”進行 消息摘要 ，隨後用自己的私鑰對摘要的內容進行加密得到 數字簽名 ，寫入紙條署名處。

6 小明收到信息，用字符a作爲密鑰進行 對稱解密 ，得到內容“同意傳紙條”。爲了鑑別內容是否被 破壞或篡改 過，小明使用 小紅的公鑰 對署名的字符進行解密，得到 消息摘要內容a ，另外再將內容“同意傳紙條”進行消息摘要得到 消息摘要b ，最後將摘要內容a和摘要內容b進行比對，如果一致，則說明沒有破壞或篡改過。

7 通信繼續。。

至此上面幾個步驟，就完成了安全的 連接和通信 ：雙方都使用字符a作爲密鑰對內容進行對稱加密，另外生成數字簽名寫在一旁用於校驗內容。

身份驗證的實現：

此前小明不是怕第四排同學僞裝成小紅回紙條信息嗎？

現在有了 數字證書 的功能，在一開始準備傳對話內容前就可以通過CA公鑰解密數字證書，得出信息來辨別對方身份。

萬惡的第四排同學（中間人）再也無法僞裝女神小紅了！

注：HTTPS機制非常重要的一點就是假定CA的私鑰是安全的，如果泄露了，HTTPS的安全性機制將土崩瓦解。所以CA一般是大公司或組織，因爲它們更有能力保護自己的私鑰，因此瀏覽器信任的CA列表往往是一些知名CA。

數據加密的實現：

此前小明不是怕第四排同學竊聽紙條信息嗎？

現在因爲有了前面的身份驗證，也就確保得到了真實對方的公鑰，並能利用該公鑰加密傳輸即將用於 對稱加密 對話內容的密鑰（例子中的字符a）。只要這個對稱密鑰被安全傳輸了，後面進行紙條內容的加密也就被高效的實現了。

萬惡的第四排同學（中間人）再也不無法偷看我的紙條小祕密了！

注：這裏可能會有同學問，既然雙方都知道彼此的公鑰後，那爲何不直接拿對方的公鑰來加密自己要發出的信息？這個確實可以，但是卻忽略了高效性，前面已經提到過，非對稱加密算法比對稱加密算法效率要低，考慮到後續通信的頻繁性，所以最好使用對稱加密來對通信內容進行加密。

數據完整性保護的實現：

此前小明不是怕第四排同學 篡改或破壞 紙條信息嗎？

現在有了 數字簽名 ，可與原有信息進行對比，就可以判斷紙條內容有無被更改或破壞了。

萬惡的第四排同學（中間人）再也無法更改或破壞我對女神表達的情感了！

HTTPS的建立過程:

弄懂了上面小明傳紙條的例子，再來理解訪問使用 HTTPS 協議網站的建立過程，簡直就是易如反掌！

1、服務端配置正確了對應的安全證書 
2、客戶端發送請求到服務端 
3、服務端返回公鑰和證書到客戶端 
4、客戶端接收後會驗證證書的安全性，如果通過則會隨機生成一個隨機數，用公鑰對其加密，發送到服務端 
5、服務端接受到這個加密後的隨機數後會用私鑰對其解密得到真正的隨機數，隨後用這個隨機數當做密鑰對需要發送的數據進行對稱加密 
6、客戶端在接收到加密後的數據使用密鑰（即生成的隨機值）對數據進行解密並且解析數據呈現結果給客戶 
7、SSL加密建立。後續數據傳輸還將用到數字簽名技術。。

注：小明傳紙條的例子和用戶訪問網站有點不同：小明小紅互相傳紙條需要雙方互相進行身份驗證；而用戶訪問網站，只是用戶驗證網站，網站不驗證用戶。但無論哪種情況，使用的 底層技術 都是上面幾種，只是應用情況不同。