從頭至尾談一下HTTPS

引言

「你能談一下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權威指南》