HTTPS安全機制：從加密到證書全解析

1.HTTPS是什么

2.加密是什么

3.HTTPS的加密過程

3.1對稱加密

3.2非對稱加密

?4.引入證書

?4.1"中間人"攻擊

4.2 引入證書機制

4.3 理解數據簽名

4.4?非對稱加密 + 對稱加密 + 證書認證

5.常見問題

5.1 Fiddler等抓包工具，為啥能解析HTTPS的數據?

5.2 中間人有沒有可能篡改該證書?

5.3?中間人整個掉包證書呢？

5.4?為什么摘要內容在網絡傳輸的時候一定要加密形成簽名??

5.5?為什么簽名不直接加密，而是要先 hash 形成摘要??

1.HTTPS是什么

HTTPS是一個應用層協議,是在HTTP協議的基礎上引入了一個加密層的安全通信協議，核心是通過SSL/TLS 協議對傳輸數據進行加密，確保網絡通信的保密性、完整性和身份真實性

HTTP協議內容都是按照文本的方式明文傳輸的,這就導致在傳輸過程中出現一些被篡改的情況

原因:我們通過網絡傳輸的所有數據包都會經由運營商的路由器、交換機等網絡設備。這意味著運營商可以解析并篡改我們傳輸的數據內容。

當用戶點擊"下載按鈕"時，實際上是在向服務器發送HTTP請求。正常情況下，服務器返回的HTTP響應會包含該APP的下載鏈接。但運營商一旦檢測到這是"天天動聽"的下載請求，就會自動將響應內容篡改為"QQ瀏覽器"的下載地址。

為什么運營商會進行流量劫持？歸根結底是為了牟取利益。💴💴💴

HTTP明文傳輸本身就存在安全隱患，不僅運營商可以輕易劫持，黑客也同樣能從中作梗。想象一下，如果您的個人隱私、支付密碼等敏感信息被截獲，后果將多么嚴重。正是出于這樣的安全考慮，我們才需要HTTPS加密協議來保障用戶信息安全。

2.加密是什么

明文:要傳輸的原始數據
密文:對明文進行加密后使他人不能理解
加密:就是把明文(要傳輸的信息)進行一系列變換,生成密文
解密:就是把密文再進行一系列變換,還原成明文
密鑰:在這個加密解密的過程中,往往需要一個或多個中間的數據,輔助進行這個過程,這樣的數據稱為密鑰

加密解密到如今已經發展成一個獨立的學科：密碼學
而密碼學的奠基人，也正是計算機科學的祖師爺之一，艾倫·麥席森·圖靈

3.HTTPS的加密過程

為確保數據安全，需采用"加密"技術。在網絡傳輸過程中，不再直接傳送明文，而是傳輸經過加密處理的"密文"。加密方式主要分為兩大類：對稱加密和非對稱加密。

3.1對稱加密

對稱加密（Symmetric Encryption）是一種加密和解密使用同一密鑰的加密技術，也稱為 “單密鑰加密”。其核心特點是加密與解密過程共享一個密鑰，操作高效且廣泛應用于各類場景。

通過同一個"密鑰",把明文加密成密文,并且也能把密文揭密成明文

核心原理:

加密過程：明文 + 密鑰 → 通過加密算法 → 密文
解密過程：密文 + 同一密鑰 → 通過解密算法 → 明文
核心要求：加密和解密必須使用完全相同的密鑰，否則無法還原明文。

舉例一個簡單的對稱加密,按位異或

假設明文a = 1234,密鑰key = 8888;加密a^key得到的密文b就是9834

對密文9834再次進行計算b^key,得到的就是原來的明文1234

如果直接把密鑰進行明文傳輸,那么黑客也就能獲取密鑰啦,那么我們所進行的加密操作就形同虛設了,因此密鑰的傳輸也必須加密傳輸,要想對密鑰進行對稱加密,就仍然需要先協商確定一個"密鑰的密鑰",可是對稱加密又是明文傳輸,此時就陷入了死循環,

“要加密密鑰 → 需新密鑰 → 新密鑰又要加密 → 需更上層密鑰……”

此時我們就需要引入非對稱加密

3.2非對稱加密

非對稱加密（Asymmetric Encryption）是一種加密和解密使用不同密鑰的加密技術，也稱為 “公鑰加密”。其核心創新在于通過一對 “公鑰” 和 “私鑰” 實現加密與解密，解決了對稱加密中密鑰傳輸的安全難題。

公鑰不怕泄露，私鑰不能泄露

核心原理

密鑰對：由 “公鑰”（Public Key）和 “私鑰”（Private Key）組成，兩者通過數學算法關聯（如大數分解、離散對數），但從公鑰無法推導出私鑰。
加密解密過程：明文 + 公鑰 → 通過加密算法 → 密文（只有對應的私鑰能解密）。
? ? ? ? ? ? ? ? ? ? ? ? ?密文 + 私鑰 → 通過解密算法 → 明文（只有對應的公鑰能加密）。

? ? ? ? ? ? ? ? ? ? ? ? ?明文 + 私鑰 → 通過加密算法 → 密文（只有對應的公鑰能解密）。
? ? ? ? ? ? ? ? ? ? ? ? ?密文?+ 公鑰 → 通過解密算法 → 明文（只有對應的私鑰能解密）。

? ? ? ? ? ? ? ? ? ? ? ? ?公鑰加密→私鑰解密：保證 “消息只有對方能看懂”（保密通信）；
? ? ? ? ? ? ? ? ? ? ? ? ?私鑰加密→公鑰解密：保證 “消息確實是對方發的”（身份驗證）。
核心特性：公鑰可公開傳播，私鑰必須嚴格保密；用公鑰加密的數據只能用私鑰解密，反之亦然（部分算法支持 “私鑰加密、公鑰解密”，用于簽名）。

舉例:

A需要向B傳遞一些重要文件，但B可能不在場。

為此，雙方約定如下：

B告訴A："我桌上有個盒子，我會給你一把鎖"
A將文件放入盒子并用這把鎖鎖好
B隨后用對應的鑰匙開鎖取件

在這個類比中：

鎖相當于公鑰（可以公開分發）
鑰匙相當于私鑰（必須由B獨自保管）只有持有私鑰的人才能解密獲取文件內容。

非對稱加密加密傳輸對稱密鑰

客戶端在本地生成對稱密鑰,通過公鑰進行加密,發送給服務器
由于中間的網絡設備沒有私鑰,即使截獲了數據,也無法還原出內部的原文,也就無法獲取到對稱密鑰
服務器通過私鑰解密,還原出客戶端發送的對稱密鑰,并且使用這個對稱密鑰給客戶端返回響應數據
后續客戶端和服務器的通信都只用對稱加密即可,由于該密鑰只有客戶端和服務器兩個主機知道,其他主機/設備不知道密鑰即使截獲數據也沒有意義

?4.引入證書

?4.1"中間人"攻擊

客戶端如何獲取到公鑰?
客戶端如何確定這個公鑰不是黑客偽造的?

黑客通過替換公鑰，讓客戶端和服務器誤以為在安全交換密鑰，實際對稱密鑰被黑客截獲。由于非對稱加密的 “公鑰公開” 特性，客戶端無法驗證公鑰是否真實（這是單純非對稱加密的漏洞）

4.2 引入證書機制

問題的關鍵就是能夠讓客戶端識別出,拿到的公鑰是不是正確的,合理的而不是偽造的公鑰

為確保通信安全，服務端在啟用HTTPS前需向CA機構申請數字證書。該證書包含申請者信息和公鑰等關鍵數據。當服務器將證書傳輸至瀏覽器時，瀏覽器可直接從中提取公鑰。數字證書的作用類似于身份證，用于驗證服務端公鑰的真實性和權威性。

當你想搭建服務器時,使用HTTPS就需要在公證機構這里申請證書,申請時就需要提交一些資料,如,網站的域名,營業執照,備案號等
申請成功后,公證機構就生成一個"電子證書",證書內容包含

證書發布機構
證書有效期
公鑰
證書所有者
簽名:保證證書合法性的關鍵要點
...

（證書中的各個字段綜合在一起，計算校驗和,原始數據相同，計算得到的校驗和就相同，校驗和不同，說明原始數據就不同)

注:申請證書的時候,需要在特定平臺生成,會同時生成一對密鑰對,即公鑰和私鑰.這對密鑰對就是用來在網絡通信中進行明文加密及數字簽名的
其中公鑰會隨著CSR文件一起發給CA進行權威認證,服務端自己保留私鑰,用來后續進行通信(主要用來交換對稱密鑰)

4.3 理解數據簽名

數據簽名（通常稱為 “數字簽名”，Digital Signature）是一種基于密碼學的安全技術，用于驗證數據的完整性（數據未被篡改）和來源真實性（確認數據發送者身份），同時防止發送者事后抵賴。其核心邏輯基于非對稱加密和哈希算法

當服務器申請CA證書的時候,CA機構會對該服務器端進行審核,并專門為該網站形成數字簽名,過程如下

CA機構擁有非對稱加密的私鑰pri和公鑰pub
CA機構對服務端申請的證書明文數據進行hash,形成數據摘要
然后對數據摘要用CA私鑰pri加密,得到數字簽名S

服務端申請的證書明文和數字簽名S共同組成了數字證書，這樣一份數字證書就可以頒發給服務端了

如何讓驗證證書是正確的?

客戶端拿到服務端的CA證書之后，會將數據和數據簽名分開。將數據進行哈希散列形成一個哈希值。再將數據簽名使用CA機構的公鑰進行解密，也得到一個哈希值。將這兩個哈希值進行比較，如果相同，則說明證書是正確的。

服務器申請到證書之后,后續客戶端從服務器拿公鑰就不只是拿公鑰而是拿整個證書,此時客戶端就可以憑借證書中的數字簽名對證書的合法性進行驗證

客戶端如何驗證數字簽名?

客戶端把證書中的各個字段再算一遍校驗和,得到checksum1
客戶端使用公證機構的公鑰,對數字簽名進行解密,得到checksum2
對比checksum1 == checksum2 如果相等則視為當前證書的各個字段就是和服務器這邊發出來的證書是一模一樣的,此時就可以認為這是合法證書

如果不相等則意味著證書上的內容被中間的黑客篡改過了,此時瀏覽器往往就會彈出警告頁面,提示用戶該網站不安全

當前客戶端所拿的公證機構的公鑰,客戶端是如何確定這個公鑰是正確的而不是黑客偽造的?
操作系統（如 Windows、Linux、macOS）和瀏覽器（如 Chrome、Firefox）在開發時，會將一些知名且權威的 CA 機構的根證書預先內置到系統或應用程序中。這些根證書包含了 CA 機構的公鑰信息。當客戶端收到一個證書時，它會從根證書開始，按照證書鏈的順序進行驗證。例如，Windows 系統的證書存儲區中就包含了眾多受信任的 CA 根證書，瀏覽器在驗證證書時會參考這些內置的根證書信息。

黑客可不可以篡改數據后同時更新數字簽名,讓數字簽名解密出來的checksum2和篡改過的checksum1一致呢?
黑客篡改數據后，若想重新生成數字簽名，必須使用公證機構的私鑰進行加密——而這個私鑰是黑客無法獲取的。
如果黑客試圖使用自生成的私鑰呢？客戶端使用公證機構的公鑰將無法解密。
此時，解密失敗會被系統識別為證書異常，從而觸發明顯的安全警告彈窗。

4.4?非對稱加密 + 對稱加密 + 證書認證

在客戶端和服務器剛一建立連接的時候,服務器給客戶端返回一個證書,這個證書包含了剛才的公鑰,也包含了網站的身份信息

當客戶端獲取到這個證書之后,會對證書進行校驗(防止證書是偽造的)

判定證書的有效期是否過期
判斷證書的發布機構是否受信任(操作系統已內置的受信任的證書發布機構)
驗證證書是否被篡改:從系統中拿到該證書發布機構的公鑰,對簽名進行解密,得到一個hash值(稱為數據摘要),設為hash1,然后計算整個證書的hash值,設為hash2,對比hash1和hash2是否相等,如果相等,則說明證書沒有被篡改過

5.常見問題

5.1 Fiddler等抓包工具，為啥能解析HTTPS的數據?

要解密數據必須獲取對稱密鑰，而Fiddler就是通過中間人攻擊來實現這一點的。當我們開啟HTTPS選項時，系統會彈出對話框詢問是否信任Fiddler提供的證書，一旦選擇信任就允許了中間人攻擊拿到了對稱密鑰

生成自簽名根證書，經用戶安裝后獲客戶端信任，替換服務器證書；
攔截握手階段的預主密鑰和隨機數，算出會話密鑰（對稱密鑰）；
用會話密鑰解密通信數據，實現解析。

5.2 中間人有沒有可能篡改該證書?

中間人篡改了證書的明文
由于他沒有CA機構的私鑰,所以無法hash之后用私鑰加密形成簽名,那也就沒辦法對篡改后的證書形成匹配的簽名
如果強行篡改,客戶端收到該證書后會發現明文和簽名解密后的值不一致,則說明證書已被篡改,證書不可信,從而終止向服務器傳輸信息,防止信息泄露給中間人

5.3?中間人整個掉包證書呢？

?因為中間人沒有 CA 私鑰，因此無法生成與CA簽名相同的加密哈希值。所以無法制作假的證書。
所以中間人只能向 CA 申請真證書，然后用自己申請的證書進行掉包。這個確實能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務端認證信息，如果整體掉包，客戶端依舊能夠識別出來。
永遠記住：中間人沒有 CA 私鑰，所以對任何證書都無法進行合法修改，包括自己的。

5.4?為什么摘要內容在網絡傳輸的時候一定要加密形成簽名??

常見的摘要算法有:MD5和SHA系列
以MD5為例，我們不需要研究具體的計算簽名的過程，只需要了解MD5的特點：

定長：無論多長的字符串，計算出來的MD5值都是固定長度（16字節版本或者32字節版本)
分散：源字符串只要改變一點點，最終得到的MD5值都會差別很大。
不可逆：通過源字符串生成MD5很容易，但是通過MD5還原成原串理論上是不可能的.

正因為MD5有這樣的特性，我們可以認為如果兩個字符串的MD5值相同，則認為這兩個字符串相同。?

理解判定證書篡改的過程：（這個過程就好比判定這個身份證是不是偽造的身份證)
假設我們的證書只是一個簡單的字符串hello，對這個字符串計算hash值(比如md5)，結果為
BC4B2A76B9719D91
如果hello中有任意的字符被篡改了，比如變成了hella,那么計算的md5值就會變化很大.
BDBD6F9CF51F2FD8
然后我們可以把這個字符串hello和哈希值BC4B2A76B9719D91從服務器返回給客戶端，此時客戶端
如何驗證hello是否是被篡改過?
那么就只要計算hello的哈希值，看看是不是BC4B2A76B9719D91即可.

但是還有個問題，如果黑客把hello篡改了，同時也把哈希值重新計算下，客戶端就分辨不出來了呀.

所以被傳輸的哈希值不能傳輸明文，需要傳輸密文。
所以，對證書明文(這里就是“hello”)hash形成散列摘要，然后CA使用自己的私鑰加密形成簽名，將hello和加密的簽名合起來形成CA證書，頒發給服務端，當客戶端請求的時候，就發送給客戶端，中間人截獲了，因為沒有CA私鑰，就無法更改或者整體掉包，就能安全的證明，證書的合法性。
最后，客戶端通過操作系統里已經存的了的證書發布機構的公鑰進行解密，還原出原始的哈希值，再進行校驗.