HTTPS 工作原理，之前也看過(guò)一些，但是對(duì)整體的一個(gè)完整流程和部分細(xì)節(jié)，還是處于一個(gè)模糊狀態(tài)，之前也有一些疑問(wèn)：“證書(shū)是怎么驗(yàn)證的?”、“TLS 握手過(guò)程是怎么樣的?”、“對(duì)稱(chēng)密鑰如何計(jì)算?”、“計(jì)算預(yù)主密鑰隨機(jī)數(shù)用了幾個(gè)?” 等等，基于這些疑問(wèn)，也花了一些時(shí)間才逐步了解的，基于自己的理解，做了一個(gè) HTTPS 的系列文章，希望能幫助到有此疑問(wèn)的讀者朋友。
本文為系列的第一篇，帶著一些問(wèn)題逐步了解對(duì)稱(chēng)加密、非對(duì)稱(chēng)加密、數(shù)字證書(shū)、密鑰協(xié)商等這些概念分別是什么、能做什么，一層一層揭開(kāi)其神秘面紗。
使用 HTTP 潛在的問(wèn)題
在 HTTP 中數(shù)據(jù)之間的網(wǎng)絡(luò)傳輸是明文的，很容易被中間人竊取、攻擊，對(duì)數(shù)據(jù)進(jìn)行偽造再發(fā)往服務(wù)器端，服務(wù)端接收到數(shù)據(jù)也無(wú)法判斷數(shù)據(jù)的來(lái)源是否準(zhǔn)確。
如果說(shuō)為什么要使用 HTTPS?直白點(diǎn)就是 “HTTP 不安全”，無(wú)法準(zhǔn)確的保證數(shù)據(jù)的機(jī)密性、真實(shí)性、完整性。
什么是 HTTPS 協(xié)議
HTTPS 不是一種全新的協(xié)議，它是建立在 SSL/TLS 傳輸層安全協(xié)議之上的一種 HTTP 協(xié)議，相當(dāng)于 HTTPS = HTTP + SSL/TLS，可保護(hù)用戶(hù)計(jì)算機(jī)與網(wǎng)站服務(wù)器之間數(shù)據(jù)傳輸?shù)耐暾浴C(jī)密性。
從 OSI 模型圖上看主要是在應(yīng)用層和傳輸層直接多了一個(gè) SSL/TLS 協(xié)議。
這里最主要的部分 SSL/TLS 就是我們學(xué)習(xí) HTTPS 的關(guān)鍵部分，SSL/TLS 做為一種安全的加密協(xié)議，其在不安全的基礎(chǔ)設(shè)施之上為我們提供了安全的通信通道。
SSL/TLS 這個(gè)名字有時(shí)也會(huì)讓人迷，現(xiàn)在我們所說(shuō)的 SSL/TLS 一般特指 TLS 協(xié)議，不妨看下它的發(fā)展歷史。
SSL/TLS 發(fā)展歷史
SSL 是 secure socket layer 的簡(jiǎn)稱(chēng)，中文為安全套接字層。最早由網(wǎng)景(Netscape)公司開(kāi)發(fā)，該協(xié)議的第一個(gè)版本從未發(fā)布過(guò)。自 1994 年 11 月開(kāi)始發(fā)布第二個(gè)版本，SSL 2 在開(kāi)發(fā)上基本上沒(méi)有與 Netscape 公司以外的安全專(zhuān)家商討，這個(gè)版本被認(rèn)為存在嚴(yán)重缺陷，這個(gè)版本最終也以失敗告終。在 SSL2 失敗后，Netscape 專(zhuān)注于 SSL 3 進(jìn)行了完全重新的協(xié)議設(shè)計(jì)，于 1995 年發(fā)布，SSL 3 版的協(xié)議被沿用至今，只不過(guò)后來(lái)被改了名字 TLS 1.0，也許很多人并不知道。
1996 年 5 月，TLS 工作組成立，開(kāi)始將 SSL 從 Netscape 公司遷移至 IETF，由于 Netscape 與 Microsoft 在 Web 統(tǒng)治權(quán)的爭(zhēng)執(zhí)，整個(gè)遷移工作也經(jīng)歷了一個(gè)漫長(zhǎng)的過(guò)程，在 1999 年 1 月 IETF 組織將 SSL 進(jìn)行了標(biāo)準(zhǔn)化 TLS 1.0 問(wèn)世，前身就是 SSL 3。
TLS 是 transport layer security 的簡(jiǎn)稱(chēng)，中文為傳輸層安全協(xié)議。在 2006 年 4 月 TSL 1.1 版本發(fā)布，修復(fù)了一些關(guān)鍵的安全問(wèn)題，添加對(duì) CBC 攻擊的保護(hù)(隱式 IV 被替換為顯示 IV，更改分組密碼模式中的填充錯(cuò)誤)。
在 2008 年 8 月 TLS 1.2 版本發(fā)布，主要包括：增加 SHA-2 密碼散列函數(shù)、AEAD 加密算法、TLS 擴(kuò)展定義和 AES 密碼組合。
2018 年 8 月 TLS 1.3 版本發(fā)布，對(duì)安全的加強(qiáng)、性能的提升也做了很多改變，例如，在安全上將 MD5、SHA-1 這些不安全或過(guò)時(shí)的算法移除，僅保留了少數(shù)算法 ECDHA、SHA-2 等。性能上在 TLS 握手過(guò)程中由之前的 2-RTT 握手改進(jìn)為 1-RTT 握手并初步支持 0-RTT。
選擇合適加密算法
我們談到 https 都知道它之所以安全是因?yàn)閭鬏斨袑?duì)數(shù)據(jù)做了加密，首先了解下它選擇了哪種加密方式來(lái)實(shí)現(xiàn)的。
對(duì)稱(chēng)加密
對(duì)稱(chēng)加密是一種共享密鑰的算法，客戶(hù)端與服務(wù)端共用一把密鑰，對(duì)數(shù)據(jù)做加密傳輸，如果密鑰只有通信雙方持有，不保證泄漏，那就可以保證安全。
現(xiàn)實(shí)世界中顯然不是這樣的，例如瀏覽器同服務(wù)器交互，服務(wù)器把共享密鑰傳輸給瀏覽器，這個(gè)密鑰在傳輸過(guò)程中怎么保證不被截取、篡改?
非對(duì)稱(chēng)加密
進(jìn)一步提升安全系數(shù)，出現(xiàn)了 “非對(duì)稱(chēng)加密” 又稱(chēng)為 “公鑰加密”，該算法擁有兩個(gè)不對(duì)稱(chēng)的密鑰，它的特性是使用公鑰加密只有對(duì)應(yīng)的私鑰可解密，反之，私鑰加密也只有對(duì)應(yīng)的公鑰才可解密。注意，私鑰僅自己可見(jiàn)，對(duì)外暴露的是公鑰。
非對(duì)稱(chēng)加密的安全性比對(duì)稱(chēng)加密要高，但是它需要更多的計(jì)算，不適用于數(shù)據(jù)量大的場(chǎng)景，通信速度沒(méi)有了保證也不行的，TLS 加密算法并沒(méi)有完全采用這種加密算法。
混合加密
所謂 “取長(zhǎng)補(bǔ)短”，TLS 在加密算法上結(jié)合了非對(duì)稱(chēng)加密和對(duì)稱(chēng)加密，我們這里稱(chēng)之為 “混合加密” 算法，使用非對(duì)稱(chēng)加密進(jìn)行身份驗(yàn)證和共享密鑰的協(xié)商，只用一次即可，后續(xù)的通信中使用對(duì)稱(chēng)密鑰進(jìn)行數(shù)據(jù)的傳輸。
除此之外，客戶(hù)端和服務(wù)端交換公鑰的過(guò)程，依然存在被竊聽(tīng)，經(jīng)典的例子還是中間人攻擊，因?yàn)楣€在傳輸?shù)倪^(guò)程是可見(jiàn)的，中間人可以對(duì)客戶(hù)端扮演服務(wù)端的角色或者對(duì)服務(wù)端扮演客戶(hù)端的角色，依然可以對(duì)數(shù)據(jù)進(jìn)行篡改，但是服務(wù)端無(wú)法判別來(lái)源是否可靠，問(wèn)題仍然存在。
舉一個(gè)例子：
- 服務(wù)器使用非對(duì)稱(chēng)加密算法生成一對(duì)公私鑰，我們稱(chēng)為公鑰 A、私鑰 A，解決密鑰交換問(wèn)題。
- 這里還存在一個(gè)中間人，它也生成了一對(duì)公私鑰，我們稱(chēng)為公鑰 B、私鑰 B。
- 瀏覽器向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器返回自己的公鑰 A，傳輸中被中間人截取(問(wèn)題來(lái)了)，將服務(wù)器的公鑰 A 替換為中間人的公鑰 B 發(fā)往瀏覽器。
- 瀏覽器獲取到公鑰 B，并不知道這個(gè)是中間人的，它生成一個(gè)隨機(jī)數(shù)再用公鑰 B 加密，得到對(duì)稱(chēng)加密所需要的 “會(huì)話(huà)密鑰”。
- 瀏覽器將生成的 “會(huì)話(huà)密鑰” 發(fā)送給服務(wù)器，中間人截取之后使用自己測(cè)私鑰 B 解密，得到 “會(huì)話(huà)密鑰”，再用服務(wù)器公鑰 A 加密發(fā)送到服務(wù)器。
- 服務(wù)器在收到信息后，用自己的私鑰 A 解密，得到 “會(huì)話(huà)密鑰”，但服務(wù)器也不知道此時(shí)已被中間人截取了。
這也不行那該怎么辦?在這里使用 “混合加密” 從安全、性能上得到了一個(gè)平衡，使用非對(duì)稱(chēng)加密交換對(duì)稱(chēng)加密密鑰，已實(shí)現(xiàn)了我們需要的機(jī)密性。
現(xiàn)在我們要解決下一個(gè)疑問(wèn)：如何保證瀏覽器拿到的公鑰是可信的?
數(shù)字證書(shū)解決信任問(wèn)題
例如，現(xiàn)實(shí)世界里，我們?nèi)ャy行辦事，到柜臺(tái)前你說(shuō)我是張三，要辦理業(yè)務(wù)，銀行工作人員首先需要你出示證件，得證明你是真的張三，能證明自己的就是 “身份證” 了，由權(quán)威機(jī)構(gòu)(現(xiàn)實(shí)世界里的公安局)頒發(fā)的大家都認(rèn)可的證件。
網(wǎng)絡(luò)世界的 “公安局”
那么網(wǎng)絡(luò)世界里的公安局，就是我們常說(shuō)的 CA，Certificate Authority，證書(shū)認(rèn)證機(jī)構(gòu)，我們也需要為網(wǎng)站申請(qǐng)數(shù)字證書(shū)。
證書(shū)是一個(gè)包含版本、序列號(hào)、簽名算法、頒發(fā)者、有效期、公鑰等的數(shù)字證書(shū)文件。我們的網(wǎng)站在使用 HTTPS 之前都會(huì)預(yù)先向 CA 機(jī)構(gòu)申請(qǐng)一份數(shù)字證書(shū)，安裝到自己的服務(wù)器上，之后瀏覽器發(fā)起請(qǐng)求，服務(wù)器就可以把這個(gè)數(shù)字證書(shū)返回到瀏覽器，這個(gè)過(guò)程中怎么保證數(shù)字證書(shū)不被修改呢?
公安局在頒發(fā)我們的身份證時(shí)有一定的防偽技術(shù)，同樣 CA 在簽發(fā)證書(shū)時(shí)也會(huì)對(duì)證書(shū)進(jìn)行數(shù)字簽名，保證證書(shū)的完整性。
image.png
摘要算法
摘要算法是一種單向的加密算法，也稱(chēng)為 “散列算法”，在加密數(shù)據(jù)時(shí)不需要提供密鑰，加密之后的數(shù)據(jù)也不能進(jìn)行逆向推算。
它能實(shí)現(xiàn)對(duì)一個(gè)大文件加密之后映射為一個(gè)小文件，好比一篇文章提取一段摘要，但如果原文發(fā)生改變，哪怕是增加或刪除一個(gè)標(biāo)點(diǎn)符號(hào)再次加密后的結(jié)果也會(huì)發(fā)生完全不同的變化，目前一些常用的摘要算法(MD5、SHA-1)被認(rèn)為存在安全性問(wèn)題，在 TLS 1.3 版本已經(jīng)移除了，現(xiàn)在推薦的是 SHA-2，例如 SHA256。
CA 機(jī)構(gòu)對(duì)明文數(shù)據(jù)會(huì)做一個(gè)摘要算法，生成一段不可逆向解密的 Hash value，這段 Hash value 不能明文傳輸，避免中間人在修改證書(shū)后把摘要算法也修改了。
數(shù)字簽名
數(shù)字簽名，這個(gè)名字在現(xiàn)實(shí)世界也是如此，例如我給你一個(gè)證明，要證明是我給你的，最有效的辦法就是簽名、按手印，這個(gè)是沒(méi)辦法偽造的。
CA 也有一對(duì)自己的公私鑰，結(jié)合上面摘要算法生成的 hash value，使用 CA 私鑰加上這段 hash value 來(lái)生成數(shù)字簽名，這個(gè)只有對(duì)應(yīng)的公鑰才可解密。
數(shù)字證書(shū)
CA 將數(shù)字簽名和我們申請(qǐng)的信息(服務(wù)器名稱(chēng)、公鑰、主機(jī)名、權(quán)威機(jī)構(gòu)的名稱(chēng)、信息等)整合到一塊，生成數(shù)字證書(shū)，頒發(fā)給服務(wù)器。
下面是對(duì) www.nodejs.red 這個(gè)域名截取的一張圖。
有了數(shù)字證書(shū)，客戶(hù)端和服務(wù)端在交互時(shí)就可使用非對(duì)稱(chēng)密鑰來(lái)協(xié)商用于數(shù)據(jù)加密的對(duì)稱(chēng)加密密鑰了。
協(xié)商對(duì)稱(chēng)加密密鑰
證書(shū)驗(yàn)證
我們?cè)跒g覽器打開(kāi)一個(gè) HTTPS 協(xié)議的網(wǎng)址發(fā)起請(qǐng)求，在建立 TCP 鏈接之后，會(huì)發(fā)起 TLS 的握手協(xié)議，之后服務(wù)器會(huì)返回一系列消息，其中就包括證書(shū)消息。
證書(shū)的驗(yàn)證存在一個(gè)證書(shū)信任鏈問(wèn)題，我們向 CA 申請(qǐng)的證書(shū)，通常是由中間證書(shū)機(jī)構(gòu)頒發(fā)的。例如，www.nodejs.red 這個(gè)域名你會(huì)看到它的證書(shū)簽發(fā)者是 “R3”，它是 Let's Encrypt 在 2020 年 11 月 20 日推出的一個(gè)免費(fèi)證書(shū)，通過(guò) R3 我們可以找到它的簽發(fā)者是 “ISRG Root X1”，而 “ISRG Root X1” 沒(méi)有了上級(jí)的簽發(fā)者，現(xiàn)在會(huì)認(rèn)為它是根證書(shū)。
下圖展示的是 www.nodejs.red 這個(gè)域名網(wǎng)站的證書(shū)鏈關(guān)系。
在我們的操作系統(tǒng)中會(huì)預(yù)先安裝一些權(quán)威機(jī)構(gòu)的證書(shū)，瀏覽器信任的是根證書(shū)，如果根證書(shū)在本地，就用根證書(shū) “ISRG Root X1” 公鑰去驗(yàn)證 “ISRG Root X1” 這個(gè)中間證書(shū)機(jī)構(gòu)是否可信，如果校驗(yàn)通過(guò)，再用 “ISRG Root X1” 去驗(yàn)證最終的實(shí)體證書(shū) “www.nodejs.red” 是否可信任，如果通過(guò)就認(rèn)為證書(shū) “www.nodejs.red” 是可信的。
證書(shū)驗(yàn)證基本上都是這種模式，最終要找到本地安裝的根證書(shū)，在反向的逐級(jí)驗(yàn)證，確認(rèn)網(wǎng)站的簽發(fā)者是可信的。如下圖所示。
如果服務(wù)器返回的證書(shū)驗(yàn)證通過(guò)，瀏覽器就可獲取到數(shù)字證書(shū)的明文、簽名信息，做以下操作：
- 用 CA 機(jī)構(gòu)的公鑰(CA 機(jī)構(gòu)的公鑰是不需要傳輸?shù)模僮飨到y(tǒng)提供的根證書(shū)里會(huì)存在)去解密簽名，得到摘要算法計(jì)算出的 hash value，我們暫定名稱(chēng)為 hashCode1。
- 用證書(shū)里指定的摘要算法對(duì)明文數(shù)據(jù)做加密，得到 hashCode2。
- 如果明文數(shù)據(jù)未被篡改，hashCode2 應(yīng)該等于 hashCode1。
- 現(xiàn)在證書(shū)是可信的，就可拿到服務(wù)器的公鑰。
如果證書(shū)信息被篡改，沒(méi)有證書(shū)私鑰是不能改簽名的，客戶(hù)端收到證書(shū)之后對(duì)原文信息做個(gè)簽名一比對(duì)就知道是否被篡改。
另一個(gè)問(wèn)題，假設(shè)：“我們的證書(shū)被黑客用合法證書(shū)調(diào)包呢?”，證書(shū)的域名等信息是不能被篡改的，就算黑客調(diào)包換成了自己的合法證書(shū)，因?yàn)橛蛎畔⒉灰粯樱瑸g覽器請(qǐng)求的時(shí)候一對(duì)比也可發(fā)現(xiàn)問(wèn)題。
沒(méi)有絕對(duì)的安全，如果黑客把自己的根證書(shū)安裝在了你的計(jì)算機(jī)上，那么它就可以簽發(fā)任意域名的虛假證書(shū)了，因此，遇到一些不可信的文件還是不要亂安裝的好，保證根證書(shū)的安全。
計(jì)算加密密鑰
上面瀏覽器向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器返回證書(shū)，這個(gè)過(guò)程雙方會(huì)交換兩個(gè)參數(shù)，分別是客戶(hù)端的隨機(jī)數(shù)、服務(wù)端的隨機(jī)數(shù)，用于生成主密鑰，但是主密鑰的生成還依賴(lài)一個(gè)預(yù)主密鑰。
不同的密鑰交換算法，生成預(yù)主密鑰的方法也不同。一種密鑰交換算法是 RSA，它的密鑰交換過(guò)程很簡(jiǎn)單，由客戶(hù)端生成預(yù)主密鑰，為 46 字節(jié)的隨機(jī)數(shù)，使用服務(wù)器的公鑰加密，經(jīng)過(guò)密鑰交換消息發(fā)送到服務(wù)端，服務(wù)端再用私鑰就可解密出這個(gè)預(yù)主密鑰。
基于 RSA 的密鑰交換算法被認(rèn)為存在嚴(yán)重的漏洞威脅，任何能夠接觸到私鑰的人(例如，由于政治、賄賂、強(qiáng)行進(jìn)入等)都可恢復(fù)預(yù)主密鑰，進(jìn)而構(gòu)建相同的主密鑰，最終密鑰泄漏就可解密之前記錄的所有流量了。這種密鑰交換算法正在被支持前向保密的其它算法替代，例如，ECDHE 算法在密鑰交換時(shí)，每個(gè)鏈接使用的主密鑰相互獨(dú)立，如果出現(xiàn)問(wèn)題也只是影響到當(dāng)前會(huì)話(huà)，不能用于追溯解密任何其它的流量。
ECDHE 是臨時(shí)橢圓曲線(xiàn)密鑰交換算法，客戶(hù)端和服務(wù)器會(huì)分別交換兩個(gè)信息 Server Params、Client Params，在每次的鏈接中，都會(huì)生成一對(duì)新的臨時(shí)公私鑰。基于 ECDHE 算法客戶(hù)端和服務(wù)端可分別計(jì)算出預(yù)主密鑰(premaster secret)
這時(shí)客戶(hù)端和服務(wù)端就分別擁有 Client Random、Server Random、Premaster Secret 三個(gè)隨機(jī)數(shù)。
主密鑰在 TLS v1.2 是通過(guò)一個(gè)偽隨機(jī)函數(shù) master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) 計(jì)算出來(lái)的。
但主密鑰并不是最終的會(huì)話(huà)密鑰，最終的會(huì)話(huà)密鑰使用 PRF 偽隨機(jī)函數(shù)傳入主密鑰、客戶(hù)端隨機(jī)數(shù)、服務(wù)端隨機(jī)數(shù)生成。
- key_block = PRF(master_secret, "key expansion", server_random + client_random)
這個(gè)最終的會(huì)話(huà)密鑰包括：對(duì)稱(chēng)加密密鑰(symmetric key)、消息認(rèn)證碼密鑰(mac key)、初始化項(xiàng)量(iv key，只在必要時(shí)生成)
上面這些都是在 TLS 的握手協(xié)議中完成的，當(dāng)握手完成之后，客戶(hù)端/服務(wù)端建立一個(gè)安全通信隧道，就可以發(fā)送應(yīng)用程序數(shù)據(jù)了。
HTTPS 完整過(guò)程圖示
協(xié)商對(duì)稱(chēng)加密密鑰，這里面主要就是 TLS 的握手協(xié)議，這個(gè)過(guò)程很復(fù)雜，還有很多內(nèi)容本篇最后沒(méi)有詳細(xì)的講解，下圖為筆者畫(huà)的一個(gè)握手交互圖，在下一篇文章中會(huì)通過(guò) Wireshark 工具來(lái)抓取網(wǎng)絡(luò)數(shù)據(jù)包做分析，做一個(gè)實(shí)戰(zhàn)講解，更深刻的理解 HTTPS 的原理。
原文鏈接：https://mp.weixin.qq.com/s?__biz=MzU3NTg5MjU1Mw==&mid=2247484501&idx=1&sn=744e6c655876a219ed0853a1f2b7aeaa&chksm=fd1d7973ca6af065de03fd2eeca288bedd738e2fea7c88632a315663c330f67b06db8a92c2b6&mpshare=1&s
