HTTPS 工作原理，之前也看過一些，但是對整體的一個完整流程和部分細節(jié)，還是處于一個模糊狀態(tài)，之前也有一些疑問：“證書是怎么驗證的?”、“TLS 握手過程是怎么樣的?”、“對稱密鑰如何計算?”、“計算預主密鑰隨機數(shù)用了幾個?” 等等，基于這些疑問，也花了一些時間才逐步了解的，基于自己的理解，做了一個 HTTPS 的系列文章，希望能幫助到有此疑問的讀者朋友。

[[442088]]

本文為系列的第一篇，帶著一些問題逐步了解對稱加密、非對稱加密、數(shù)字證書、密鑰協(xié)商等這些概念分別是什么、能做什么，一層一層揭開其神秘面紗。

使用 HTTP 潛在的問題

在 HTTP 中數(shù)據(jù)之間的網(wǎng)絡(luò)傳輸是明文的，很容易被中間人竊取、攻擊，對數(shù)據(jù)進行偽造再發(fā)往服務(wù)器端，服務(wù)端接收到數(shù)據(jù)也無法判斷數(shù)據(jù)的來源是否準確。

如果說為什么要使用 HTTPS?直白點就是 “HTTP 不安全”，無法準確的保證數(shù)據(jù)的機密性、真實性、完整性。

什么是 HTTPS 協(xié)議

HTTPS 不是一種全新的協(xié)議，它是建立在 SSL/TLS 傳輸層安全協(xié)議之上的一種 HTTP 協(xié)議，相當于 HTTPS = HTTP + SSL/TLS，可保護用戶計算機與網(wǎng)站服務(wù)器之間數(shù)據(jù)傳輸?shù)耐暾浴C密性。

從 OSI 模型圖上看主要是在應用層和傳輸層直接多了一個 SSL/TLS 協(xié)議。

這里最主要的部分 SSL/TLS 就是我們學習 HTTPS 的關(guān)鍵部分，SSL/TLS 做為一種安全的加密協(xié)議，其在不安全的基礎(chǔ)設(shè)施之上為我們提供了安全的通信通道。

SSL/TLS 這個名字有時也會讓人迷，現(xiàn)在我們所說的 SSL/TLS 一般特指 TLS 協(xié)議，不妨看下它的發(fā)展歷史。

SSL/TLS 發(fā)展歷史

SSL 是 secure socket layer 的簡稱，中文為安全套接字層。最早由網(wǎng)景(Netscape)公司開發(fā)，該協(xié)議的第一個版本從未發(fā)布過。自 1994 年 11 月開始發(fā)布第二個版本，SSL 2 在開發(fā)上基本上沒有與 Netscape 公司以外的安全專家商討，這個版本被認為存在嚴重缺陷，這個版本最終也以失敗告終。在 SSL2 失敗后，Netscape 專注于 SSL 3 進行了完全重新的協(xié)議設(shè)計，于 1995 年發(fā)布，SSL 3 版的協(xié)議被沿用至今，只不過后來被改了名字 TLS 1.0，也許很多人并不知道。

1996 年 5 月，TLS 工作組成立，開始將 SSL 從 Netscape 公司遷移至 IETF，由于 Netscape 與 Microsoft 在 Web 統(tǒng)治權(quán)的爭執(zhí)，整個遷移工作也經(jīng)歷了一個漫長的過程，在 1999 年 1 月 IETF 組織將 SSL 進行了標準化 TLS 1.0 問世，前身就是 SSL 3。

TLS 是 transport layer security 的簡稱，中文為傳輸層安全協(xié)議。在 2006 年 4 月 TSL 1.1 版本發(fā)布，修復了一些關(guān)鍵的安全問題，添加對 CBC 攻擊的保護(隱式 IV 被替換為顯示 IV，更改分組密碼模式中的填充錯誤)。

在 2008 年 8 月 TLS 1.2 版本發(fā)布，主要包括：增加 SHA-2 密碼散列函數(shù)、AEAD 加密算法、TLS 擴展定義和 AES 密碼組合。

2018 年 8 月 TLS 1.3 版本發(fā)布，對安全的加強、性能的提升也做了很多改變，例如，在安全上將 MD5、SHA-1 這些不安全或過時的算法移除，僅保留了少數(shù)算法 ECDHA、SHA-2 等。性能上在 TLS 握手過程中由之前的 2-RTT 握手改進為 1-RTT 握手并初步支持 0-RTT。

選擇合適加密算法

我們談到 https 都知道它之所以安全是因為傳輸中對數(shù)據(jù)做了加密，首先了解下它選擇了哪種加密方式來實現(xiàn)的。

對稱加密

對稱加密是一種共享密鑰的算法，客戶端與服務(wù)端共用一把密鑰，對數(shù)據(jù)做加密傳輸，如果密鑰只有通信雙方持有，不保證泄漏，那就可以保證安全。

現(xiàn)實世界中顯然不是這樣的，例如瀏覽器同服務(wù)器交互，服務(wù)器把共享密鑰傳輸給瀏覽器，這個密鑰在傳輸過程中怎么保證不被截取、篡改?

非對稱加密

進一步提升安全系數(shù)，出現(xiàn)了 “非對稱加密” 又稱為 “公鑰加密”，該算法擁有兩個不對稱的密鑰，它的特性是使用公鑰加密只有對應的私鑰可解密，反之，私鑰加密也只有對應的公鑰才可解密。注意，私鑰僅自己可見，對外暴露的是公鑰。

非對稱加密的安全性比對稱加密要高，但是它需要更多的計算，不適用于數(shù)據(jù)量大的場景，通信速度沒有了保證也不行的，TLS 加密算法并沒有完全采用這種加密算法。

混合加密

所謂 “取長補短”，TLS 在加密算法上結(jié)合了非對稱加密和對稱加密，我們這里稱之為 “混合加密” 算法，使用非對稱加密進行身份驗證和共享密鑰的協(xié)商，只用一次即可，后續(xù)的通信中使用對稱密鑰進行數(shù)據(jù)的傳輸。

除此之外，客戶端和服務(wù)端交換公鑰的過程，依然存在被竊聽，經(jīng)典的例子還是中間人攻擊，因為公鑰在傳輸?shù)倪^程是可見的，中間人可以對客戶端扮演服務(wù)端的角色或者對服務(wù)端扮演客戶端的角色，依然可以對數(shù)據(jù)進行篡改，但是服務(wù)端無法判別來源是否可靠，問題仍然存在。

舉一個例子：

• 服務(wù)器使用非對稱加密算法生成一對公私鑰，我們稱為公鑰 A、私鑰 A，解決密鑰交換問題。
• 這里還存在一個中間人，它也生成了一對公私鑰，我們稱為公鑰 B、私鑰 B。
• 瀏覽器向服務(wù)器發(fā)起請求，服務(wù)器返回自己的公鑰 A，傳輸中被中間人截取(問題來了)，將服務(wù)器的公鑰 A 替換為中間人的公鑰 B 發(fā)往瀏覽器。
• 瀏覽器獲取到公鑰 B，并不知道這個是中間人的，它生成一個隨機數(shù)再用公鑰 B 加密，得到對稱加密所需要的 “會話密鑰”。
• 瀏覽器將生成的 “會話密鑰” 發(fā)送給服務(wù)器，中間人截取之后使用自己測私鑰 B 解密，得到 “會話密鑰”，再用服務(wù)器公鑰 A 加密發(fā)送到服務(wù)器。
• 服務(wù)器在收到信息后，用自己的私鑰 A 解密，得到 “會話密鑰”，但服務(wù)器也不知道此時已被中間人截取了。

這也不行那該怎么辦?在這里使用 “混合加密” 從安全、性能上得到了一個平衡，使用非對稱加密交換對稱加密密鑰，已實現(xiàn)了我們需要的機密性。

現(xiàn)在我們要解決下一個疑問：如何保證瀏覽器拿到的公鑰是可信的?

數(shù)字證書解決信任問題

例如，現(xiàn)實世界里，我們?nèi)ャy行辦事，到柜臺前你說我是張三，要辦理業(yè)務(wù)，銀行工作人員首先需要你出示證件，得證明你是真的張三，能證明自己的就是 “身份證” 了，由權(quán)威機構(gòu)(現(xiàn)實世界里的公安局)頒發(fā)的大家都認可的證件。

網(wǎng)絡(luò)世界的 “公安局”

那么網(wǎng)絡(luò)世界里的公安局，就是我們常說的 CA，Certificate Authority，證書認證機構(gòu)，我們也需要為網(wǎng)站申請數(shù)字證書。

證書是一個包含版本、序列號、簽名算法、頒發(fā)者、有效期、公鑰等的數(shù)字證書文件。我們的網(wǎng)站在使用 HTTPS 之前都會預先向 CA 機構(gòu)申請一份數(shù)字證書，安裝到自己的服務(wù)器上，之后瀏覽器發(fā)起請求，服務(wù)器就可以把這個數(shù)字證書返回到瀏覽器，這個過程中怎么保證數(shù)字證書不被修改呢?

公安局在頒發(fā)我們的身份證時有一定的防偽技術(shù)，同樣 CA 在簽發(fā)證書時也會對證書進行數(shù)字簽名，保證證書的完整性。

image.png

摘要算法

摘要算法是一種單向的加密算法，也稱為 “散列算法”，在加密數(shù)據(jù)時不需要提供密鑰，加密之后的數(shù)據(jù)也不能進行逆向推算。

它能實現(xiàn)對一個大文件加密之后映射為一個小文件，好比一篇文章提取一段摘要，但如果原文發(fā)生改變，哪怕是增加或刪除一個標點符號再次加密后的結(jié)果也會發(fā)生完全不同的變化，目前一些常用的摘要算法(MD5、SHA-1)被認為存在安全性問題，在 TLS 1.3 版本已經(jīng)移除了，現(xiàn)在推薦的是 SHA-2，例如 SHA256。

CA 機構(gòu)對明文數(shù)據(jù)會做一個摘要算法，生成一段不可逆向解密的 Hash value，這段 Hash value 不能明文傳輸，避免中間人在修改證書后把摘要算法也修改了。

數(shù)字簽名

數(shù)字簽名，這個名字在現(xiàn)實世界也是如此，例如我給你一個證明，要證明是我給你的，最有效的辦法就是簽名、按手印，這個是沒辦法偽造的。

CA 也有一對自己的公私鑰，結(jié)合上面摘要算法生成的 hash value，使用 CA 私鑰加上這段 hash value 來生成數(shù)字簽名，這個只有對應的公鑰才可解密。

數(shù)字證書

CA 將數(shù)字簽名和我們申請的信息(服務(wù)器名稱、公鑰、主機名、權(quán)威機構(gòu)的名稱、信息等)整合到一塊，生成數(shù)字證書，頒發(fā)給服務(wù)器。

下面是對 www.nodejs.red 這個域名截取的一張圖。

有了數(shù)字證書，客戶端和服務(wù)端在交互時就可使用非對稱密鑰來協(xié)商用于數(shù)據(jù)加密的對稱加密密鑰了。

協(xié)商對稱加密密鑰

證書驗證

我們在瀏覽器打開一個 HTTPS 協(xié)議的網(wǎng)址發(fā)起請求，在建立 TCP 鏈接之后，會發(fā)起 TLS 的握手協(xié)議，之后服務(wù)器會返回一系列消息，其中就包括證書消息。

證書的驗證存在一個證書信任鏈問題，我們向 CA 申請的證書，通常是由中間證書機構(gòu)頒發(fā)的。例如，www.nodejs.red 這個域名你會看到它的證書簽發(fā)者是 “R3”，它是 Let's Encrypt 在 2020 年 11 月 20 日推出的一個免費證書，通過 R3 我們可以找到它的簽發(fā)者是 “ISRG Root X1”，而 “ISRG Root X1” 沒有了上級的簽發(fā)者，現(xiàn)在會認為它是根證書。

下圖展示的是 www.nodejs.red 這個域名網(wǎng)站的證書鏈關(guān)系。

在我們的操作系統(tǒng)中會預先安裝一些權(quán)威機構(gòu)的證書，瀏覽器信任的是根證書，如果根證書在本地，就用根證書 “ISRG Root X1” 公鑰去驗證 “ISRG Root X1” 這個中間證書機構(gòu)是否可信，如果校驗通過，再用 “ISRG Root X1” 去驗證最終的實體證書 “www.nodejs.red” 是否可信任，如果通過就認為證書 “www.nodejs.red” 是可信的。

證書驗證基本上都是這種模式，最終要找到本地安裝的根證書，在反向的逐級驗證，確認網(wǎng)站的簽發(fā)者是可信的。如下圖所示。

如果服務(wù)器返回的證書驗證通過，瀏覽器就可獲取到數(shù)字證書的明文、簽名信息，做以下操作：

• 用 CA 機構(gòu)的公鑰(CA 機構(gòu)的公鑰是不需要傳輸?shù)?，操作系統(tǒng)提供的根證書里會存在)去解密簽名，得到摘要算法計算出的 hash value，我們暫定名稱為 hashCode1。
• 用證書里指定的摘要算法對明文數(shù)據(jù)做加密，得到 hashCode2。
• 如果明文數(shù)據(jù)未被篡改，hashCode2 應該等于 hashCode1。
• 現(xiàn)在證書是可信的，就可拿到服務(wù)器的公鑰。

如果證書信息被篡改，沒有證書私鑰是不能改簽名的，客戶端收到證書之后對原文信息做個簽名一比對就知道是否被篡改。

另一個問題，假設(shè)：“我們的證書被黑客用合法證書調(diào)包呢?”，證書的域名等信息是不能被篡改的，就算黑客調(diào)包換成了自己的合法證書，因為域名信息不一樣，瀏覽器請求的時候一對比也可發(fā)現(xiàn)問題。

沒有絕對的安全，如果黑客把自己的根證書安裝在了你的計算機上，那么它就可以簽發(fā)任意域名的虛假證書了，因此，遇到一些不可信的文件還是不要亂安裝的好，保證根證書的安全。

計算加密密鑰

上面瀏覽器向服務(wù)器發(fā)起請求，服務(wù)器返回證書，這個過程雙方會交換兩個參數(shù)，分別是客戶端的隨機數(shù)、服務(wù)端的隨機數(shù)，用于生成主密鑰，但是主密鑰的生成還依賴一個預主密鑰。

不同的密鑰交換算法，生成預主密鑰的方法也不同。一種密鑰交換算法是 RSA，它的密鑰交換過程很簡單，由客戶端生成預主密鑰，為 46 字節(jié)的隨機數(shù)，使用服務(wù)器的公鑰加密，經(jīng)過密鑰交換消息發(fā)送到服務(wù)端，服務(wù)端再用私鑰就可解密出這個預主密鑰。

基于 RSA 的密鑰交換算法被認為存在嚴重的漏洞威脅，任何能夠接觸到私鑰的人(例如，由于政治、賄賂、強行進入等)都可恢復預主密鑰，進而構(gòu)建相同的主密鑰，最終密鑰泄漏就可解密之前記錄的所有流量了。這種密鑰交換算法正在被支持前向保密的其它算法替代，例如，ECDHE 算法在密鑰交換時，每個鏈接使用的主密鑰相互獨立，如果出現(xiàn)問題也只是影響到當前會話，不能用于追溯解密任何其它的流量。

ECDHE 是臨時橢圓曲線密鑰交換算法，客戶端和服務(wù)器會分別交換兩個信息 Server Params、Client Params，在每次的鏈接中，都會生成一對新的臨時公私鑰?；?ECDHE 算法客戶端和服務(wù)端可分別計算出預主密鑰(premaster secret)

這時客戶端和服務(wù)端就分別擁有 Client Random、Server Random、Premaster Secret 三個隨機數(shù)。

主密鑰在 TLS v1.2 是通過一個偽隨機函數(shù) master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) 計算出來的。

但主密鑰并不是最終的會話密鑰，最終的會話密鑰使用 PRF 偽隨機函數(shù)傳入主密鑰、客戶端隨機數(shù)、服務(wù)端隨機數(shù)生成。

key_block = PRF(master_secret, "key expansion", server_random + client_random) 

這個最終的會話密鑰包括：對稱加密密鑰(symmetric key)、消息認證碼密鑰(mac key)、初始化項量(iv key，只在必要時生成)

上面這些都是在 TLS 的握手協(xié)議中完成的，當握手完成之后，客戶端/服務(wù)端建立一個安全通信隧道，就可以發(fā)送應用程序數(shù)據(jù)了。

HTTPS 完整過程圖示

協(xié)商對稱加密密鑰，這里面主要就是 TLS 的握手協(xié)議，這個過程很復雜，還有很多內(nèi)容本篇最后沒有詳細的講解，下圖為筆者畫的一個握手交互圖，在下一篇文章中會通過 Wireshark 工具來抓取網(wǎng)絡(luò)數(shù)據(jù)包做分析，做一個實戰(zhàn)講解，更深刻的理解 HTTPS 的原理。