引言
“你能談一下HTTPS嗎？”
“一種比HTTP安全的協議。”
“...”
如果面試這樣說的話那差不多就gg了，其實HTTPS要展開回答的話內容還挺豐富的。本篇文章詳細介紹了HTTPS是什么、為什么安全以及實現安全的方法，一起來學習吧。
本文略長，請保持耐心。
https是什么？
HTTPS是以安全為目標的HTTP通道，簡單講是HTTP的安全版。之所以安全是因為它在將HTTP報文發送給TCP之前，先將其發送給了一個安全層(通過SSL協議實現)對報文進行加密。
報文加密的優點
- 保證客戶端和服務器的對話不會被其他人竊聽
- 保證雙方發送的數據不會中途被修改
- 確保雙方的身份是真實客戶端/服務器而不是偽造的客戶端/服務器
不妨將報文想象成A給B寫的一封信，A將信放在一個有鎖的盒子里，那么旁人就不能獲取信的內容也不能篡改信了。
加密機制
先了解幾個術語
- 明文：未加密的報文
- 密文：通過加密算法加密后的報文
- 密鑰：改變加密算法行為的參數
比如我們有一個加密函數，算法如下
function E(key, p) { // 將p的每一個字母向右移動key位，比如key為3則A-->D、B-->E... } E(3, "AB"); // DE
明文： "AB" ------ 密文： "DE" ------ 密鑰：3
如果我們的密鑰不一樣那么我們的加密函數執行結果就會不同。
下面來看一下常見的幾種加密機制。
對稱加密
我們之前說過，讓報文加密是為了保證我兩的聊天內容是秘密的，只有我兩能看懂，別人看不懂。那么我們要約定一個加密方式，比如咱倆遞小紙條交流的時候把小紙條裝在一個盒子里，然后只有我們有這個盒子的鑰匙。其他人就算拿到這個盒子他也打不開，那就無從竊取內容了。
對稱加密就是這個意思：發送方用密鑰將明文加密，接收方用同樣的密鑰解密。
雖然安全性得到了保障，但是還是存在兩個問題：
- 發送雙方約定密鑰時需要將密鑰在網絡傳輸，可能會造成密鑰泄露，安全得不到保障。
- 就是發送方與接收方在互相對話之前一定要有有一個共享密鑰。試想，如果N個客戶端都要與服務器建立安全通信，那么服務器需要保存N個密鑰，N和客戶端和N個服務器通信，那么將有N^2個密鑰，管理起來非常不便。
非對稱加密
非對稱加密和對稱加密是反着干的，對稱加密是使用同一個密鑰，而非對稱加密使用了兩個不同的密鑰：公鑰、私鑰，一個密鑰加密的內容只能由另一個密鑰解開。
公鑰是眾所周知的，而私鑰只有主機才持有。
服務器生成了公鑰A和私鑰B，當客戶端想給該服務器發送報文時，首先找到服務器的公鑰，然后根據公鑰A將報文加密，服務器用私鑰B解密。同理，當服務器想給該客戶端發送報文時，首先找到客戶端的公鑰C，然后根據公鑰C將報文加密，客戶端用自己的私鑰D解密。
在確保了信息安全的同時又可以方便密鑰的管理。
由此，對稱加密和非對稱加密的區別是：
| . | 對稱加密 | 非對稱加密 |
|---|---|---|
| 密鑰 | 加密解密用相同密鑰 | 公鑰、私鑰，一個加密另一個解密 |
| 密鑰管理 | 密鑰數量大，不方便 | 每個主機只需管理一對公鑰、私鑰 |
| 安全性 | 不安全（並非該機制不安全，而是雙方在約定密鑰時可能會密鑰泄露） | 安全（不需要通過對話約定密鑰） |
| 加/解密速度 | 快 | 慢 |
那HTTPS是采用的什么機制呢？
HTTPS加密機制
劇透，HTTPS對報文采用的對稱加密。
完整的一次HTTPS交流
(1) 客戶端通過TCP三次握手建立到服務器端口443（HTTPS的默認端口）的TCP連接
(2) 客戶端通過SSL握手建立安全層
(3) 客戶端發送http報文到SSL安全層，安全層將報文加密后發給TCP --> IP --> ...
(4) 同理服務器發送響應，客戶端接收后通過SSL安全層解密發給應用層
(5) SSL安全層關閉通知
(6) TCP關閉連接
從上面的描述可以清晰的看到我們的報文加密/解密都是在SSL安全層執行。
那么安全層是怎么加密的？密鑰又是怎么約定的？這一切的一切都得仔細聊聊第(2)步驟。
SSL握手
(1) 客戶端向服務器發送可供選擇的加密算法並請求證書。
客戶端說：“嘿，小子。我這里有一堆我支持的加密算法，你選一個你喜歡的發給我。對了，順便把你的身份證復印件發給我看看，我怕我連接的服務器是偽造的。”
(2) 服務器發送選中的加密算法和證書
服務器說：“emmm...我看加密算法A挺好的，咱倆就用這個吧。證書也發給你，證明我不是壞人。”
(3) 客戶端保存服務器選擇的加密算法和秘鑰A以作為日后加密，將A用服務器的公鑰B加密后發給服務器，服務器用自己的秘鑰C解密后得到A，從此客戶端和服務器都用約定的加密算法以及秘鑰A進行對稱加密。
（看到了伐？先用非對稱加密在網絡中傳輸對稱加密的秘鑰A，之后對報文都是采用對稱加密啦。）
(4) 客戶端和服務器互相告知，開始加密過程。
在SSL握手之后我們就可以開開心心的發送和接收加密報文啦。
以上是HTTPS加密的全過程，不過還不足以構成完整的HTTPS，因為完整的HTTPS要保障兩個方面的安全：報文安全、身份安全，加密只能保證報文是安全的，不能保證身份是正確的。
試想，A和B互相寫信並且交換盒子鑰匙，然后將信放盒子里寄出去，上面的加密行為可以讓A和B之間寫的信內容不會被他人獲取，但是如果一開始和A通信的就不是B呢？是竊取者C偽裝成B和A通信，那么A會和C在SSL的時候就交流鑰匙然后C可以竊取A寫給B的信的內容。
身份的認證我們用數字證書。
數字證書
含有數字證書的報文的結構：
剛剛SSL握手的第(1)步還記得伐？客戶端向服務器索要證書，這個證書是服務器可以證明自己身份的東西，該證書里包含了服務器的一些基本信息，比如站點的DNS主機名、該站點組織名、站點的公鑰（發公鑰就是為了讓客戶端SSL方便執行握手(3)）等，以及證書的序列號、證書簽名算法、過期日期等證書信息。
數字簽名
證書是一個站點的身份證，但是身份證也可以被偽造，為了保證這個證書是真的我們需要數字簽名。我們會將證書內容用簽名算法生成一個值，我們稱之為“摘要”。然后將該摘要用主機的私鑰加密，加密后的內容就是我們的數字簽名。
當客戶端收到附帶數字簽名的數字證書時，會通過數字證書中的證書簽名算法將該證書生成一個摘要，在用服務器眾所周知的公鑰解密數字簽名，看得到的摘要是否相同，相同那就說明證書是真的。
如果公鑰解密后得到的摘要與生成的摘要不符那么可能有兩種情況
- 發送方身份不是目的主機
- 目的主機發送的證書被篡改
數字證書和加密就構成了一個完整的HTTPS事務。
總結
- HTTPS之所以安全是因為有兩個保障
- 雙方的會話內容加密，旁人不能竊取
- 雙方的身份是真實的，防止竊取者偽造身份
- 內容安全
- 非對稱加密機制加密“對稱加密所需密鑰”
- 對稱加密機制加密報文
- 身份安全
- 數字證書
- 數字簽名
- 確認發送方身份
- 確認證書未被篡改
參考書籍：
《HTTP權威指南》