從“v我50”到“瘋狂星期四”：HTTPS如何用47天壽命的證書擋住中間人
最近看到一篇IT之家的新聞，《SSL/TLS證書最長有效期將縮短至47天》
?
圖片
以前 SSL/TLS 證書最長有效期可以長達 8 年，不過經過幾次調整后當前證書有效期最長為 398 天約 13 個月，也就是說無論如何開發者和企業都必須在 13 個月左右更新一次數字證書。
而蘋果提交的 SC-081v3 草案目前已經獲得行業組織的同意，簡單來說最終 SSL/TLS 證書有效期將被縮短至 47 天，整個過程將循序漸進的推廣，即逐步縮短有效期直到達成縮短至 47 天。
隨著SSL/TLS證書有效期的逐步縮減，也意味著CA/Browser Forum（證書頒發機構/瀏覽器論壇）對安全性日益關注。試想，在公共 Wi-Fi 下打開手機銀行應用，準備轉賬時，賬戶余額、密碼等敏感信息卻可能被不法分子攔截篡改，導致資金被盜。這并非駭人聽聞，而是網絡 “中間人攻擊” 常見場景。幸運的是，HTTPS 協議作為網絡安全重要防線，能有效抵御此類威脅。那么HTTPS協議是如何運作的，證書驗證過程又是怎么樣的呢？這篇文章帶你來一探究竟。
一、為什么需要加密
HTTP協議在設計之初并未考慮安全性，所有數據以明文形式在網絡中傳輸。這種設計在開放、可信的早期互聯網環境中尚可接受，但在當今復雜的網絡環境下，其缺陷暴露無遺：
明文數據會經過中間代理服務器、路由器、wifi熱點、通信服務運營商等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊。所以我們才需要對信息進行加密。
二、常見的加密方式
加密方式主要分為兩大類，對稱加密和非對稱加密
2.1 對稱加密
加密和解密雙方使用相同的密鑰來進行數據的加密和解密操作。常見的對稱加密算法有 AES（高級加密標準）、DES（數據加密標準）等。
以 AES算法 為例，它將明文數據按照一定的塊大小（通常是 128 位）進行分組，然后通過多輪復雜的運算（包括字節替換、行移位、列混淆和輪密鑰加等操作），最終將明文轉換為密文，也可使用同樣的方法將密文轉換為明文。在這個過程中，同一個密鑰既用于將明文加密成密文，也用于將密文解密回明文。
2.2 非對稱加密
非對稱加密則涉及兩個不同的密鑰，即公鑰（Public Key）和私鑰（Secret Key）。公鑰可以無限制對外公開，而私鑰則要嚴格保密。加密時使用公鑰加密的數據，只有對應的私鑰才能解密；反過來，用私鑰加密的數據，也只有對應的公鑰才能解密。常見的非對稱加密算法有RSA（Rivest-Shamir-Adleman）、ECC（橢圓曲線密碼學）等
以 RSA 算法為例，它是基于大整數因數分解難題的非對稱加密算法。在加密時，將明文數據轉化為大整數，然后用接收方的公鑰（包含兩個大質數的乘積等信息）按照一定的數學規則進行運算，得到密文。而解密時，只有使用與該公鑰配對的私鑰（包含這兩個大質數等關鍵信息），才能通過逆向的數學運算解密回明文。
三、HTTPS證書驗證過程
3.1 明文通信
首先從最簡單明文通信開始。存在一個服務端Server和一個客戶端Client。這里跳過TCP/IP握手過程，直接進入到ESTABLISHED狀態。在不進行任何信息加密的情況下，通信過程可參考下圖
image-20240624210007543
1.客戶端Client向服務端Server明文發送信息【v我50】
2.Server收到消息后向Client明文回復消息【瘋狂星期四】
3.Client喜笑顏開如果整個通信過程Client和Server僅通過一根網線直接連接的話，那么通信的安全性是完全沒有問題的。但是真實的通信鏈路會經過中間代理服務器、路由器、wifi熱點、通信服務運營商等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊（MITM）。通信過程可參考下圖
圖片
1.客戶端Client向服務端Server明文發送信息【v我50】
2.中間人MiddleMan劫持到消息后，篡改為【轉我50】
3.Server收到消息后向Client明文回復消息【我們不熟】
4.MiddleMan劫持到消息后沒有篡改消息，直接回復給了Client
5.Client留下了傷心的淚水為了防止MiddleMan劫持后可以看到消息內容，可以考慮通過加密的方式進行通信，先從簡單的對稱加密通信開始嘗試
3.2 對稱加密通信
對稱加密中加密的密鑰和解密的密鑰是一致的。這里使用E1來表示密鑰。假設Client和Server已經在保密的情況下分別獲取到了E1。通信過程可參考下圖
圖片
1.客戶端Client使用密鑰E1加密明文【v我50】生成密文【U2FsdGVkX1】
2.Client向服務端Server發送密文【U2FsdGVkX1】
3.Server接收到【U2FsdGVkX1】后使用E1進行解密得到【v我50】
4.Server使用E1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
5.Server向Client發送密文【S6Vk01J1u】
6.Client接收到【S6Vk01J1u】并使用E1進行解密得到【瘋狂星期四】
7.Client喜笑顏開這個通信過程看起來足夠安全，但是還記得我們的前提嗎，Client和Server已經在保密的情況下分別獲取到了E1。
如何做到保密呢。是否可以提前存儲在Client和Server上。在實際的網絡環境中，會有很多臺客戶端C2、C3或很多臺S2、S3等。這就要考慮不同的Client和Server是否都使用E1。如果是，那么MiddleMan也可以拿到E1，如果不是，雙方就要存儲全世界所有的密鑰，即使很多Server我們終生也不會訪問。而且又涉及到密鑰更新和廢除的問題。
那么可以通過網絡通信交換E1嗎，其實這樣和明文傳輸沒有實質區別。通信過程可參考下圖
圖片
1.客戶端Client向服務端Server詢問【使用的對稱密鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發送給了Server
3.Server收到消息后明文回復消息【就用E1吧】
4.MiddleMan劫持到消息，保存下E1后，將消息【就用E1吧】明文回復給了Client
5.Client使用E1加密消息【v我50】，生成密文【U2FsdGVkX1】，發送給Server
6.MiddleMan劫持到消息，使用E1解密得到【v我50】
7.MiddleMan篡改消息為【轉我50】并使用E1加密，生成密文【eG55ddqk】，發送給Server
8.Server收到消息，使用E1解密得到【轉我50】，使用E1加密消息【我們不熟】，生成密文【S6Vk01J1u】，回復給Client
9.MiddleMan劫持到消息，使用E1解密得到【我們不熟】，沒有進行篡改發送給了Client
10.Client收到消息【S6Vk01J1u】，使用E1解密得到【我們不熟】
11.Client留下了傷心的淚水這個通信過程可以發現僅使用對稱加密是無法解決通信安全性的問題的，那么使用非對稱加密呢。
3.3 非對稱加密通信
由于僅使用對稱加密是無法解決通信安全性的問題，因此考慮使用非對稱加密。非對稱加密包含一組密鑰，公鑰和私鑰。使用公鑰加密的數據，只有對應的私鑰才能解密；反過來，使用私鑰加密的數據，也只有對應的公鑰才能解密。公鑰可以無限制對外公開，而私鑰則要嚴格保密。假設服務端擁有公鑰PK1和私鑰SK1。通信過程可參考下圖
圖片
1.客戶端Client向服務端Server詢問【你的公鑰是什么】
2.Server收到消息后明文回復消息【我的公鑰是：PK1】
3.Client使用公鑰PK1加密明文【v我50】生成密文【U2FsdGVkX1】
4.Client向服務端Server發送密文【U2FsdGVkX1】
5.Server接收到【U2FsdGVkX1】后使用私鑰SK1進行解密得到【v我50】
6.Server使用SK1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
7.Server向Client發送密文【S6Vk01J1u】
8.Client接收到【S6Vk01J1u】并使用PK1進行解密得到【瘋狂星期四】
9.Client喜笑顏開由于公鑰是無限制公開的，那么中間人也可以正常拿到公鑰PK1，此時中間人攻擊過程可參考下圖：
圖片
1.客戶端Client向服務端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發送給了Server
3.Server收到消息后明文回復消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將消息【我的公鑰是：PK1】明文回復給了Client
5.Client使用PK1加密消息【v我50】，生成密文【U2FsdGVkX1】，發送給Server
6.MiddleMan劫持到消息【U2FsdGVkX1】，由于沒有Server的私鑰SK1，所以無法解密消息，只能將消息發送給Server
7.Server收到消息，使用SK1解密得到【v我50】，Server使用SK1加密明文【瘋狂星期四】生成密文【S6Vk01J1u】
8.Server向Client發送密文【S6Vk01J1u】
9.MiddleMan劫持到消息，使用PK1解密消息得到【瘋狂星期四】，不過由于沒有SK1，無法對消息進行篡改，便將消息發送給了Client
10.Client接收到【S6Vk01J1u】并使用PK1進行解密得到【瘋狂星期四】
11.Client喜笑顏開這種方式雖然MiddleMan無法篡改信息，也無法知道Client向Server發送的信息內容。但是可以知道來自Server的消息內容。所以這種通信模式僅可以保證Client向Server單向通信是安全的（當然這種模式還有其他更嚴重的漏洞，在這里先不展開）。那么這是不是可以利用這一特點。Client生成對稱加密密鑰安全的傳遞給Server，之后雙方使用對稱加密密鑰進行加解密。這種通信方式稱為混合加密通信。
3.4 混合加密通信
混合解密通信是先通過非對稱加密協商出對稱加密密鑰，之后通過對稱加密方式進行實時通信的過程。這樣即使中間人劫取了信息，由于無法獲取到對稱加密密鑰，所以也無法對信息進行加解密。假設協商的對稱加密密鑰為E1，通信過程可參考下圖
圖片
1.客戶端Client向服務端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發送給了Server
3.Server收到消息后明文回復消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將消息【我的公鑰是：PK1】明文回復給了Client
5.Client使用PK1加密已經準備好的對稱密鑰【E1】，生成密文【pTyLGTddEr】，發送給Server
6.MiddleMan劫持到消息【pTyLGTddEr】，由于沒有Server的私鑰SK1，所以無法解密消息，只能將消息發送給Server
7.Server收到消息，使用SK1解密得到【E1】，Server使用E1加密明文【Finished】生成密文【BFgENlNcc】
8.Server向Client發送密文【BFgENlNcc】
9.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發送給了Client
10.Client接收到【BFgENlNcc】并使用【E1】解密得到【Finished】，便知道Server已經準備好了
11.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】，而后發送給Server
12.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發送給了Server
13.Server接收到【U2FsdGVkX1】后使用E1解密得到明文【v我50】
14.Server使用E1加密消息【瘋狂星期四】得到密文【S6Vk01J1u】，發送給Client
15.MiddleMan劫持到消息，由于沒有對稱加密的密鑰E1，所以無法解密消息，便將消息發送給了Client
16.Client收到消息【S6Vk01J1u】，使用E1解密得到【瘋狂星期四】
17.Client喜笑顏開在這種通信模式下，看起來已經足夠安全了，但是還記得在上文提到的這種模式還有其他更嚴重的漏洞嗎。現在一起來分析下中間人還能通過什么方式獲取信息呢。假設中間人擁有自己的公鑰PK2和私鑰SK2，通信過程可參考下圖
圖片
1.客戶端Client向服務端Server詢問【你的公鑰是什么】
2.中間人MiddleMan劫持到消息后沒有篡改消息，發送給了Server
3.Server收到消息后明文回復消息【我的公鑰是：PK1】
4.MiddleMan劫持到消息，保存下PK1后，將PK1篡改成自己的公鑰PK2，明文回復給【我的公鑰是：PK2】Client
5.Client使用PK2加密已經準備好的對稱密鑰【E1】，生成密文【pTyLGTddEr】，發送給Server
6.MiddleMan劫持到消息【pTyLGTddEr】，使用自己的私鑰SK2解密得到E1
7.保存下E1后，使用PK1加密E1得到密文【2FsdGVkX1】，發送給Server
8.Server收到消息，使用SK1解密得到【E1】，Server使用E1加密明文【Finished】生成密文【BFgENlNcc】
9.Server向Client發送密文【BFgENlNcc】
10.MiddleMan劫持到消息，使用E1解密得到【Finished】，沒有篡改消息，便將消息發送給了Client
11.Client接收到【BFgENlNcc】并使用【E1】解密得到【Finished】，便認為Server已經準備好了
12.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】，而后發送給Server
13.MiddleMan劫持到消息，使用E1解密消息得到【v我50】
14.MiddleMan將消息【v我50】篡改成【轉我50】并使用E1加密得到密文【eG55ddqk】，將消息發送給了Server
15.Server接收到【eG55ddqk】后使用E1解密得到明文【轉我50】
16.Server使用E1加密消息【我們不熟】得到密文【S6Vk01J1u】，發送給Client
17.MiddleMan劫持到消息，沒有篡改消息，便將消息發送給了Client
18.Client收到消息【S6Vk01J1u】，使用E1解密得到【我們不熟】
19.Client留下了傷心的淚水中間人通過一招貍貓換太子劫取到了全部的信息。而問題的根源就在于Client無法驗證Server返回證書的身份，也就只能無條件相信證書的合法性。那么是否可以像指紋一樣每個人（證書）都有一個特定的紋理（數字簽名）。這樣Client就可以像驗證指紋一樣驗證證書的合法性了。這也就是CA機構（證書授權機構）的核心作用了。
四、CA(Certificate Authority)證書授權機構
簡單介紹下CA機構的發展史。1994年網景公司 （Netscape）推出了SSL1.0。隨后， SSL 2.0 和 SSL 3.0 相繼發布。1999年， IETF （國際互聯網工程任務組）將SSL 3.0改進后標準化為 TLS 1.0 。為了便于協同制訂SSL/TLS證書等安全規范。CA/Browser Forum（CA/瀏覽器論壇）于2005年正式成立。
那么證書授權機構是如何解決證書網絡傳播的身份不確定問題的呢。所有合規的企業和具有完全民事行為能力的個人都可以申請CA數字證書。CA數字證書主要包含三部分。證書明文信息T（包含公鑰、域名、企業信息）、摘要算法M和數字簽名S。以百度的公開數字證書為例。如下圖：
圖片
那么數字證書是如何生成的呢，可參考下圖。
圖片
1.證書明文信息T包含公鑰、域名、企業信息
2.通過協商好的摘要算法M進行散列得到Hash值
3.簽發者（CA機構）使用私鑰對Hash值進行加密得到數字簽名S（證書指紋）
4.數字簽名S和證書明文信息T組合起來，生成CA證書CA機構認證的證書就安全了嗎，可以從下面兩個方向進行討論。
4.1 中間人有可能篡改該證書嗎
假設中間人篡改了證書的原文，由于他沒有CA機構的私鑰，所以無法得到此時加密后簽名，無法相應地篡改簽名。Client收到該證書后會發現原文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向Server傳輸信息，防止信息泄露給中間人。
既然不可能篡改，那整個證書被掉包呢？
4.2 中間人有可能把證書掉包嗎
假設有另一個ClientB也拿到了CA機構認證的證書，它想劫持ClientA的信息。于是它成為中間人攔截到了Sever傳給ClientA的證書，然后替換成自己的證書，傳給ClientA。之后ClientA就會錯誤地拿到ClientB的證書里的公鑰了，那么這里就會導致上文“中間人攻擊”那里提到的漏洞嗎？
其實這并不會發生，因為證書里包含了Server的信息，包括域名、企業信息等。計算機把證書里的域名與自己請求的域名比對一下就知道有沒有被掉包了。
五、完整的證書驗證過程
經過上述的介紹，HTTPS證書的驗證過程已經基本介紹完了，而在實際通信過程中對稱加密的密鑰E1并不是由Client生成然后傳輸給Server的。而是通過SSL/TLS四次握手協商產生的。完整的協商和通信流程可參考下圖
圖片
1.客戶端Client向服務端Server詢問【你的CA證書是什么】，攜帶支持的TLS協議版本、加密套件和生成的隨機數RandomA
2.中間人MiddleMan劫持到消息后沒有篡改消息，發送給了Server
3.Server收到消息后，回復消息【我的證書是CA1】，攜帶選擇的TLS協議版本、加密套件、生成的隨機數RandomB以及Server的公鑰PK1
4.MiddleMan劫持到消息后，由于沒有Server的私鑰SK1，無法篡改信息，而如果將CA1偷換成自己的證書CA2，則無法通過Client的根證書合法性校驗，所以只能將消息原樣發送給Client。
5.Client接收到消息后，首先驗證證書的合法性。驗證通過后會生成第三個隨機數RandomC。并使用PK1進行加密生成密文【HtjyMfqw】
6.Client將密文【HtjyMfqw】發送給Server，同時使用已知的RandomA、RandomB、RandomC通過協商的加密套件生成對稱密鑰E1。
7.MiddleMan劫持到消息【HtjyMfqw】后，由于沒有Server的私鑰SK1，無法對消息進行解密，因此只能將消息原樣發送給Server
8.Server收到消息后，使用SK1解密消息得到RandomC
9.Server使用已知的RandomA、RandomB、RandomC通過協商的加密套件生成對稱密鑰E1，而后使用E1加密消息【Finished】生成密文【BFgENlNcc】
10.Server將密文發送給Client
11.MiddleMan劫持到消息后，由于無法知道RandomC，因此也無法計算出E1，只能將消息原樣發送給Client
12.Client接收到消息后，使用E1解密消息【BFgENlNcc】得到【Finished】，便知道Server準備好了
13.Client使用E1加密消息【v我50】得到密文【U2FsdGVkX1】發送給Server
14.MiddleMan劫持到消息后，由于無法知道E1，因此無法解密消息，只能將消息原樣發送給Server
15.Server使用E1解密消息得到【v我50】，而后使用E1加密消息【瘋狂星期四】生成密文【S6Vk01J1u】回復Client
16.MiddleMan劫持到消息后，由于無法知道E1，因此無法解密消息，只能將消息原樣發送給Client
17.Client接收到消息后，使用E1解密消息【S6Vk01J1u】得到【瘋狂星期四】
18.Client喜笑顏開這樣的驗證過程看起來已經足夠安全了，為什么還要逐步縮減證書的有效期到47天呢？實際上并沒有絕對安全的加密方式，RSA加密算法的安全性依賴于大整數分解的計算復雜度。隨著計算機算力的不斷提升，RSA的安全性的根基也面臨著更大的挑戰。因此逐步降低證書有效期可以有效的提高證書安全性。
六、寫在最后
本文整體的過程是基于HTTPS單向認證的。HTTPS雙向認證會增加Server對Client證書的認證。由于基本過程類似，不在這里進行額外分析。
HTTPS 證書驗證過程融合多種加密技術與安全機制，是現代互聯網安全的基石。它不僅保護了個人隱私，也為企業數據傳輸提供了可靠保障。在數字化浪潮下，理解并重視 HTTPS 協議，對每一位網絡參與者都至關重要。未來，HTTPS 協議將繼續演進，適應日益復雜的網絡環境，為網絡通信安全保駕護航。
七、參考文檔
- 知乎專欄 :【https://zhuanlan.zhihu.com/p/43789231】
- GlobalSign :【https://www.globalsign.cn/blog_detailed_225】
- hpbn.co :【https://hpbn.co/】
