最近看到一篇IT之家的新聞，《SSL/TLS證書最長有效期將縮短至47天》

?

圖片

以前 SSL/TLS 證書最長有效期可以長達(dá) 8 年，不過經(jīng)過幾次調(diào)整后當(dāng)前證書有效期最長為 398 天約 13 個月，也就是說無論如何開發(fā)者和企業(yè)都必須在 13 個月左右更新一次數(shù)字證書。

而蘋果提交的 SC-081v3 草案目前已經(jīng)獲得行業(yè)組織的同意，簡單來說最終 SSL/TLS 證書有效期將被縮短至 47 天，整個過程將循序漸進(jìn)的推廣，即逐步縮短有效期直到達(dá)成縮短至 47 天。

隨著SSL/TLS證書有效期的逐步縮減，也意味著CA/Browser Forum（證書頒發(fā)機(jī)構(gòu)/瀏覽器論壇）對安全性日益關(guān)注。試想，在公共 Wi-Fi 下打開手機(jī)銀行應(yīng)用，準(zhǔn)備轉(zhuǎn)賬時，賬戶余額、密碼等敏感信息卻可能被不法分子攔截篡改，導(dǎo)致資金被盜。這并非駭人聽聞，而是網(wǎng)絡(luò) “中間人攻擊” 常見場景。幸運(yùn)的是，HTTPS 協(xié)議作為網(wǎng)絡(luò)安全重要防線，能有效抵御此類威脅。那么HTTPS協(xié)議是如何運(yùn)作的，證書驗證過程又是怎么樣的呢？這篇文章帶你來一探究竟。

一、為什么需要加密

HTTP協(xié)議在設(shè)計之初并未考慮安全性，所有數(shù)據(jù)以明文形式在網(wǎng)絡(luò)中傳輸。這種設(shè)計在開放、可信的早期互聯(lián)網(wǎng)環(huán)境中尚可接受，但在當(dāng)今復(fù)雜的網(wǎng)絡(luò)環(huán)境下，其缺陷暴露無遺：

明文數(shù)據(jù)會經(jīng)過中間代理服務(wù)器、路由器、wifi熱點、通信服務(wù)運(yùn)營商等多個物理節(jié)點，如果信息在傳輸過程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是中間人攻擊。所以我們才需要對信息進(jìn)行加密。

二、常見的加密方式

加密方式主要分為兩大類，對稱加密和非對稱加密

2.1 對稱加密

加密和解密雙方使用相同的密鑰來進(jìn)行數(shù)據(jù)的加密和解密操作。常見的對稱加密算法有 AES（高級加密標(biāo)準(zhǔn)）、DES（數(shù)據(jù)加密標(biāo)準(zhǔn)）等。

以 AES算法 為例，它將明文數(shù)據(jù)按照一定的塊大小（通常是 128 位）進(jìn)行分組，然后通過多輪復(fù)雜的運(yùn)算（包括字節(jié)替換、行移位、列混淆和輪密鑰加等操作），最終將明文轉(zhuǎn)換為密文，也可使用同樣的方法將密文轉(zhuǎn)換為明文。在這個過程中，同一個密鑰既用于將明文加密成密文，也用于將密文解密回明文。

2.2 非對稱加密

非對稱加密則涉及兩個不同的密鑰，即公鑰（Public Key）和私鑰（Secret Key）。公鑰可以無限制對外公開，而私鑰則要嚴(yán)格保密。加密時使用公鑰加密的數(shù)據(jù)，只有對應(yīng)的私鑰才能解密；反過來，用私鑰加密的數(shù)據(jù)，也只有對應(yīng)的公鑰才能解密。常見的非對稱加密算法有RSA（Rivest-Shamir-Adleman）、ECC（橢圓曲線密碼學(xué)）等

以 RSA 算法為例，它是基于大整數(shù)因數(shù)分解難題的非對稱加密算法。在加密時，將明文數(shù)據(jù)轉(zhuǎn)化為大整數(shù)，然后用接收方的公鑰（包含兩個大質(zhì)數(shù)的乘積等信息）按照一定的數(shù)學(xué)規(guī)則進(jìn)行運(yùn)算，得到密文。而解密時，只有使用與該公鑰配對的私鑰（包含這兩個大質(zhì)數(shù)等關(guān)鍵信息），才能通過逆向的數(shù)學(xué)運(yùn)算解密回明文。

三、HTTPS證書驗證過程

3.1 明文通信

首先從最簡單明文通信開始。存在一個服務(wù)端Server和一個客戶端Client。這里跳過TCP/IP握手過程，直接進(jìn)入到ESTABLISHED狀態(tài)。在不進(jìn)行任何信息加密的情況下，通信過程可參考下圖

image-20240624210007543

1.客戶端Client向服務(wù)端Server明文發(fā)送信息【v我50】
2.Server收到消息后向Client明文回復(fù)消息【瘋狂星期四】
3.Client喜笑顏開

如果整個通信過程Client和Server僅通過一根網(wǎng)線直接連接的話，那么通信的安全性是完全沒有問題的。但是真實的通信鏈路會經(jīng)過中間代理服務(wù)器、路由器、wifi熱點、通信服務(wù)運(yùn)營商等多個物理節(jié)點，如果信息在傳輸過程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是中間人攻擊（MITM）。通信過程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server明文發(fā)送信息【v我50】
2.中間人MiddleMan劫持到消息后，篡改為【轉(zhuǎn)我50】
3.Server收到消息后向Client明文回復(fù)消息【我們不熟】
4.MiddleMan劫持到消息后沒有篡改消息，直接回復(fù)給了Client
5.Client留下了傷心的淚水

為了防止MiddleMan劫持后可以看到消息內(nèi)容，可以考慮通過加密的方式進(jìn)行通信，先從簡單的對稱加密通信開始嘗試

3.2 對稱加密通信

對稱加密中加密的密鑰和解密的密鑰是一致的。這里使用E1來表示密鑰。假設(shè)Client和Server已經(jīng)在保密的情況下分別獲取到了E1。通信過程可參考下圖

圖片

1.客戶端Client使用密鑰E1加密明文【v我50】生成密文【U2FsdGVkX1】
2.Client向服務(wù)端Server發(fā)送密文【U2FsdGVkX1】
3.Server接收到【U2FsdGVkX1】后使用E1進(jìn)行解密得到【v我50】
4.Server使用E1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
5.Server向Client發(fā)送密文【S6Vk01J1u】
6.Client接收到【S6Vk01J1u】并使用E1進(jìn)行解密得到【瘋狂星期四】
7.Client喜笑顏開

這個通信過程看起來足夠安全，但是還記得我們的前提嗎，Client和Server已經(jīng)在保密的情況下分別獲取到了E1。

如何做到保密呢。是否可以提前存儲在Client和Server上。在實際的網(wǎng)絡(luò)環(huán)境中，會有很多臺客戶端C2、C3或很多臺S2、S3等。這就要考慮不同的Client和Server是否都使用E1。如果是，那么MiddleMan也可以拿到E1，如果不是，雙方就要存儲全世界所有的密鑰，即使很多Server我們終生也不會訪問。而且又涉及到密鑰更新和廢除的問題。

那么可以通過網(wǎng)絡(luò)通信交換E1嗎，其實這樣和明文傳輸沒有實質(zhì)區(qū)別。通信過程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server詢問【使用的對稱密鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發(fā)送給了Server
3.Server收到消息后明文回復(fù)消息【就用E1吧】
4.MiddleMan劫持到消息，保存下E1后，將消息【就用E1吧】明文回復(fù)給了Client
5.Client使用E1加密消息【v我50】，生成密文【U2FsdGVkX1】，發(fā)送給Server
6.MiddleMan劫持到消息，使用E1解密得到【v我50】
7.MiddleMan篡改消息為【轉(zhuǎn)我50】并使用E1加密，生成密文【eG55ddqk】，發(fā)送給Server
8.Server收到消息，使用E1解密得到【轉(zhuǎn)我50】，使用E1加密消息【我們不熟】，生成密文【S6Vk01J1u】，回復(fù)給Client
9.MiddleMan劫持到消息，使用E1解密得到【我們不熟】，沒有進(jìn)行篡改發(fā)送給了Client
10.Client收到消息【S6Vk01J1u】，使用E1解密得到【我們不熟】
11.Client留下了傷心的淚水

這個通信過程可以發(fā)現(xiàn)僅使用對稱加密是無法解決通信安全性的問題的，那么使用非對稱加密呢。

3.3 非對稱加密通信

由于僅使用對稱加密是無法解決通信安全性的問題，因此考慮使用非對稱加密。非對稱加密包含一組密鑰，公鑰和私鑰。使用公鑰加密的數(shù)據(jù)，只有對應(yīng)的私鑰才能解密；反過來，使用私鑰加密的數(shù)據(jù)，也只有對應(yīng)的公鑰才能解密。公鑰可以無限制對外公開，而私鑰則要嚴(yán)格保密。假設(shè)服務(wù)端擁有公鑰PK1和私鑰SK1。通信過程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server詢問【你的公鑰是什么】
2.Server收到消息后明文回復(fù)消息【我的公鑰是：PK1】
3.Client使用公鑰PK1加密明文【v我50】生成密文【U2FsdGVkX1】
4.Client向服務(wù)端Server發(fā)送密文【U2FsdGVkX1】
5.Server接收到【U2FsdGVkX1】后使用私鑰SK1進(jìn)行解密得到【v我50】
6.Server使用SK1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
7.Server向Client發(fā)送密文【S6Vk01J1u】
8.Client接收到【S6Vk01J1u】并使用PK1進(jìn)行解密得到【瘋狂星期四】
9.Client喜笑顏開

由于公鑰是無限制公開的，那么中間人也可以正常拿到公鑰PK1，此時中間人攻擊過程可參考下圖：

圖片

1.客戶端Client向服務(wù)端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發(fā)送給了Server
3.Server收到消息后明文回復(fù)消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將消息【我的公鑰是：PK1】明文回復(fù)給了Client
5.Client使用PK1加密消息【v我50】，生成密文【U2FsdGVkX1】，發(fā)送給Server
6.MiddleMan劫持到消息【U2FsdGVkX1】，由于沒有Server的私鑰SK1，所以無法解密消息，只能將消息發(fā)送給Server
7.Server收到消息，使用SK1解密得到【v我50】，Server使用SK1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
8.Server向Client發(fā)送密文【S6Vk01J1u】
9.MiddleMan劫持到消息，使用PK1解密消息得到【瘋狂星期四】，不過由于沒有SK1，無法對消息進(jìn)行篡改，便將消息發(fā)送給了Client
10.Client接收到【S6Vk01J1u】并使用PK1進(jìn)行解密得到【瘋狂星期四】
11.Client喜笑顏開

這種方式雖然MiddleMan無法篡改信息，也無法知道Client向Server發(fā)送的信息內(nèi)容。但是可以知道來自Server的消息內(nèi)容。所以這種通信模式僅可以保證Client向Server單向通信是安全的（當(dāng)然這種模式還有其他更嚴(yán)重的漏洞，在這里先不展開）。那么這是不是可以利用這一特點。Client生成對稱加密密鑰安全的傳遞給Server，之后雙方使用對稱加密密鑰進(jìn)行加解密。這種通信方式稱為混合加密通信。

3.4 混合加密通信

混合解密通信是先通過非對稱加密協(xié)商出對稱加密密鑰，之后通過對稱加密方式進(jìn)行實時通信的過程。這樣即使中間人劫取了信息，由于無法獲取到對稱加密密鑰，所以也無法對信息進(jìn)行加解密。假設(shè)協(xié)商的對稱加密密鑰為E1，通信過程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發(fā)送給了Server
3.Server收到消息后明文回復(fù)消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將消息【我的公鑰是：PK1】明文回復(fù)給了Client
5.Client使用PK1加密已經(jīng)準(zhǔn)備好的對稱密鑰【E1】，生成密文【pTyLGTddEr】，發(fā)送給Server
6.MiddleMan劫持到消息【pTyLGTddEr】，由于沒有Server的私鑰SK1，所以無法解密消息，只能將消息發(fā)送給Server
7.Server收到消息，使用SK1解密得到【E1】，Server使用E1加密明文【Finished】生成密文【BFgENlNcc】
8.Server向Client發(fā)送密文【BFgENlNcc】
9.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發(fā)送給了Client
10.Client接收到【BFgENlNcc】并使用【E1】解密得到【Finished】，便知道Server已經(jīng)準(zhǔn)備好了
11.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】，而后發(fā)送給Server
12.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發(fā)送給了Server
13.Server接收到【U2FsdGVkX1】后使用E1解密得到明文【v我50】
14.Server使用E1加密消息【瘋狂星期四】得到密文【S6Vk01J1u】，發(fā)送給Client
15.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發(fā)送給了Client
16.Client收到消息【S6Vk01J1u】，使用E1解密得到【瘋狂星期四】
17.Client喜笑顏開

在這種通信模式下，看起來已經(jīng)足夠安全了，但是還記得在上文提到的這種模式還有其他更嚴(yán)重的漏洞嗎?，F(xiàn)在一起來分析下中間人還能通過什么方式獲取信息呢。假設(shè)中間人擁有自己的公鑰PK2和私鑰SK2，通信過程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發(fā)送給了Server
3.Server收到消息后明文回復(fù)消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將PK1篡改成自己的公鑰PK2，明文回復(fù)給【我的公鑰是：PK2】Client
5.Client使用PK2加密已經(jīng)準(zhǔn)備好的對稱密鑰【E1】，生成密文【pTyLGTddEr】，發(fā)送給Server
6.MiddleMan劫持到消息【pTyLGTddEr】，使用自己的私鑰SK2解密得到E1
7.保存下E1后，使用PK1加密E1得到密文【2FsdGVkX1】，發(fā)送給Server
8.Server收到消息，使用SK1解密得到【E1】，Server使用E1加密明文【Finished】生成密文【BFgENlNcc】
9.Server向Client發(fā)送密文【BFgENlNcc】
10.MiddleMan劫持到消息，使用E1解密得到【Finished】，沒有篡改消息，便將消息發(fā)送給了Client
11.Client接收到【BFgENlNcc】并使用【E1】解密得到【Finished】，便認(rèn)為Server已經(jīng)準(zhǔn)備好了
12.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】，而后發(fā)送給Server
13.MiddleMan劫持到消息，使用E1解密消息得到【v我50】
14.MiddleMan將消息【v我50】篡改成【轉(zhuǎn)我50】并使用E1加密得到密文【eG55ddqk】，將消息發(fā)送給了Server
15.Server接收到【eG55ddqk】后使用E1解密得到明文【轉(zhuǎn)我50】
16.Server使用E1加密消息【我們不熟】得到密文【S6Vk01J1u】，發(fā)送給Client
17.MiddleMan劫持到消息，沒有篡改消息，便將消息發(fā)送給了Client
18.Client收到消息【S6Vk01J1u】，使用E1解密得到【我們不熟】
19.Client留下了傷心的淚水

中間人通過一招貍貓換太子劫取到了全部的信息。而問題的根源就在于Client無法驗證Server返回證書的身份，也就只能無條件相信證書的合法性。那么是否可以像指紋一樣每個人（證書）都有一個特定的紋理（數(shù)字簽名）。這樣Client就可以像驗證指紋一樣驗證證書的合法性了。這也就是CA機(jī)構(gòu)（證書授權(quán)機(jī)構(gòu)）的核心作用了。

四、CA(Certificate Authority)證書授權(quán)機(jī)構(gòu)

簡單介紹下CA機(jī)構(gòu)的發(fā)展史。1994年網(wǎng)景公司 （Netscape）推出了SSL1.0。隨后， SSL 2.0 和 SSL 3.0 相繼發(fā)布。1999年， IETF （國際互聯(lián)網(wǎng)工程任務(wù)組）將SSL 3.0改進(jìn)后標(biāo)準(zhǔn)化為 TLS 1.0 。為了便于協(xié)同制訂SSL/TLS證書等安全規(guī)范。CA/Browser Forum（CA/瀏覽器論壇）于2005年正式成立。

那么證書授權(quán)機(jī)構(gòu)是如何解決證書網(wǎng)絡(luò)傳播的身份不確定問題的呢。所有合規(guī)的企業(yè)和具有完全民事行為能力的個人都可以申請CA數(shù)字證書。CA數(shù)字證書主要包含三部分。證書明文信息T（包含公鑰、域名、企業(yè)信息）、摘要算法M和數(shù)字簽名S。以百度的公開數(shù)字證書為例。如下圖：

圖片

那么數(shù)字證書是如何生成的呢，可參考下圖。

圖片

1.證書明文信息T包含公鑰、域名、企業(yè)信息
2.通過協(xié)商好的摘要算法M進(jìn)行散列得到Hash值
3.簽發(fā)者（CA機(jī)構(gòu)）使用私鑰對Hash值進(jìn)行加密得到數(shù)字簽名S（證書指紋）
4.數(shù)字簽名S和證書明文信息T組合起來，生成CA證書

CA機(jī)構(gòu)認(rèn)證的證書就安全了嗎，可以從下面兩個方向進(jìn)行討論。

4.1 中間人有可能篡改該證書嗎

假設(shè)中間人篡改了證書的原文，由于他沒有CA機(jī)構(gòu)的私鑰，所以無法得到此時加密后簽名，無法相應(yīng)地篡改簽名。Client收到該證書后會發(fā)現(xiàn)原文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向Server傳輸信息，防止信息泄露給中間人。

既然不可能篡改，那整個證書被掉包呢？

4.2 中間人有可能把證書掉包嗎

假設(shè)有另一個ClientB也拿到了CA機(jī)構(gòu)認(rèn)證的證書，它想劫持ClientA的信息。于是它成為中間人攔截到了Sever傳給ClientA的證書，然后替換成自己的證書，傳給ClientA。之后ClientA就會錯誤地拿到ClientB的證書里的公鑰了，那么這里就會導(dǎo)致上文“中間人攻擊”那里提到的漏洞嗎？

其實這并不會發(fā)生，因為證書里包含了Server的信息，包括域名、企業(yè)信息等。計算機(jī)把證書里的域名與自己請求的域名比對一下就知道有沒有被掉包了。

五、完整的證書驗證過程

經(jīng)過上述的介紹，HTTPS證書的驗證過程已經(jīng)基本介紹完了，而在實際通信過程中對稱加密的密鑰E1并不是由Client生成然后傳輸給Server的。而是通過SSL/TLS四次握手協(xié)商產(chǎn)生的。完整的協(xié)商和通信流程可參考下圖

圖片

1.客戶端Client向服務(wù)端Server詢問【你的CA證書是什么】，攜帶支持的TLS協(xié)議版本、加密套件和生成的隨機(jī)數(shù)RandomA
2.中間人MiddleMan劫持到消息后沒有篡改消息，發(fā)送給了Server
3.Server收到消息后，回復(fù)消息【我的證書是CA1】，攜帶選擇的TLS協(xié)議版本、加密套件、生成的隨機(jī)數(shù)RandomB以及Server的公鑰PK1
4.MiddleMan劫持到消息后，由于沒有Server的私鑰SK1，無法篡改信息，而如果將CA1偷換成自己的證書CA2，則無法通過Client的根證書合法性校驗，所以只能將消息原樣發(fā)送給Client。
5.Client接收到消息后，首先驗證證書的合法性。驗證通過后會生成第三個隨機(jī)數(shù)RandomC。并使用PK1進(jìn)行加密生成密文【HtjyMfqw】
6.Client將密文【HtjyMfqw】發(fā)送給Server，同時使用已知的RandomA、RandomB、RandomC通過協(xié)商的加密套件生成對稱密鑰E1。
7.MiddleMan劫持到消息【HtjyMfqw】后，由于沒有Server的私鑰SK1，無法對消息進(jìn)行解密，因此只能將消息原樣發(fā)送給Server
8.Server收到消息后，使用SK1解密消息得到RandomC
9.Server使用已知的RandomA、RandomB、RandomC通過協(xié)商的加密套件生成對稱密鑰E1，而后使用E1加密消息【Finished】生成密文【BFgENlNcc】
10.Server將密文發(fā)送給Client
11.MiddleMan劫持到消息后，由于無法知道RandomC，因此也無法計算出E1，只能將消息原樣發(fā)送給Client
12.Client接收到消息后，使用E1解密消息【BFgENlNcc】得到【Finished】，便知道Server準(zhǔn)備好了
13.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】發(fā)送給Server
14.MiddleMan劫持到消息后，由于無法知道E1，因此無法解密消息，只能將消息原樣發(fā)送給Server
15.Server使用E1解密消息得到【v我50】，而后使用E1加密消息【瘋狂星期四】生成密文【S6Vk01J1u】回復(fù)Client
16.MiddleMan劫持到消息后，由于無法知道E1，因此無法解密消息，只能將消息原樣發(fā)送給Client
17.Client接收到消息后，使用E1解密消息【S6Vk01J1u】得到【瘋狂星期四】
18.Client喜笑顏開

這樣的驗證過程看起來已經(jīng)足夠安全了，為什么還要逐步縮減證書的有效期到47天呢？實際上并沒有絕對安全的加密方式，RSA加密算法的安全性依賴于大整數(shù)分解的計算復(fù)雜度。隨著計算機(jī)算力的不斷提升，RSA的安全性的根基也面臨著更大的挑戰(zhàn)。因此逐步降低證書有效期可以有效的提高證書安全性。

六、寫在最后

本文整體的過程是基于HTTPS單向認(rèn)證的。HTTPS雙向認(rèn)證會增加Server對Client證書的認(rèn)證。由于基本過程類似，不在這里進(jìn)行額外分析。

HTTPS 證書驗證過程融合多種加密技術(shù)與安全機(jī)制，是現(xiàn)代互聯(lián)網(wǎng)安全的基石。它不僅保護(hù)了個人隱私，也為企業(yè)數(shù)據(jù)傳輸提供了可靠保障。在數(shù)字化浪潮下，理解并重視 HTTPS 協(xié)議，對每一位網(wǎng)絡(luò)參與者都至關(guān)重要。未來，HTTPS 協(xié)議將繼續(xù)演進(jìn)，適應(yīng)日益復(fù)雜的網(wǎng)絡(luò)環(huán)境，為網(wǎng)絡(luò)通信安全保駕護(hù)航。

七、參考文檔

• 知乎專欄 :【https://zhuanlan.zhihu.com/p/43789231】
• GlobalSign :【https://www.globalsign.cn/blog_detailed_225】
• hpbn.co :【https://hpbn.co/】