網絡：相比于HTTP，HTTPS協議到底安全在哪？

我們知道HTTPS也是一種應用層協議，它在HTTP的基礎上有一層加密，因為HTTP的數據傳輸都是以明文方式傳輸的，所以加密主要是為了防止數據在傳輸的時候被篡改

今天我們要探討的就是什么是加密、為什么要加密（顯而易見）、如何加密

OK第一個什么是加密？

加密就是把你要發送的明文信息進行一系列變換生成密文，解密就是把密文經過一系列變換生成明文，在加密或者解密的過程中需要一些中間數據進行輔助，這個東西就叫做密鑰

為什么要加密

我們的所有流量都是要經過運營商的網絡設備（路由器，交換機），那么運營商的網絡設備就可以很輕松的獲取我們沒加密的明文數據，之后再將數據篡改，將篡改后的數據再發送給我們，這樣我們得到的就是被運營商篡改后的數據了

當我們想下載一個軟件，點擊下載鏈接，恰好這條下載請求被運營商劫持并篡改返回了一個另外軟件的下載地址，我們就不能下載我們想下載的軟件了

并且在這個過程中，我們并不知道是誰劫持了信息，可能是運營商，也可能黑客通過某個路由器節點，或者代理服務器發起劫持，這就是中間人攻擊，這些黑客可以通過售賣個人私有數據等賺取不法錢財，在互聯網中使用明文傳輸是一件很危險的事，所以我們需要對數據加密

如何加密

常見加密方式

對稱加密

采用單鑰密碼系統加密，同一個密鑰可以同時用作信息的加密和解密，這種方法叫做對稱加密，也叫但密鑰加密。特點是：算法公開、計算量小、加密速度快、加密效率高

一個簡單的對稱加密算法就可以用按位異或來實現

明文：1030 密鑰：8888

則密文：1030 ^ 8888 = 9918

之后對密文再異或上 8888 就可以得到明文

非對稱加密

需要兩個密鑰來進行加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）特點是：算法強度復雜、安全性依賴于算法與密鑰，但是由于其算法復雜，而使得加密解密的速度沒有對稱加密的速度快（這是它最大的缺點）

非對稱加密要用到的兩個密鑰：公鑰和私鑰是配對的

可以通過公鑰對明文加密變成密文，通過私鑰對密文解密變成明文；同時也可以反著來用

A 要給 B 一個重要的文件，它們使用這樣的方式， B 先給了 A 一個鎖（ B 有這個鎖的鑰匙）， A 把文件放一個盒子里面用鎖鎖住，之后放在 B 的辦公桌上。等 B 回來了再拿手上的鑰匙打開盒子拿到文件

這就是一個類似于非對稱加密的例子，鎖就是公鑰，鑰匙就是私鑰

數據摘要&&數據指紋

以上兩種稱呼都是一個東西，以下都稱呼為數據指紋

數字指紋的原理就是將數據通過hash算法生成一段固定長度的數字摘要。它本身并不是一種加密手段，但是可以用來判斷數據有沒有被篡改。特征是：因為不解密所以不算嚴格意義上的加密算法，只是進行數據對比

HTTPS的加密原理探究

方案一：使用對稱加密

理想情況下，服務器和客戶端雙方都持有一個相同密鑰，彼此間以密文傳輸數據，雙方都可以將密文通過密鑰轉換成明文。但是如何讓雙方持有一個相同的密鑰呢？是要事先商量好的吧，那么兩臺主機就要提前把密鑰發給對方咯，那如果中間人拿到了密鑰怎么辦？那又該怎么保證密鑰的安全呢？再套一層密鑰？那就成了雞生蛋，蛋生雞的問題了。所以使用對稱加密不是一個很好的方法

方案二：使用非對稱加密

如果服務器將公鑰以明文的方式發給客戶端，客戶端收到后，用公鑰加密數據后發給服務器，服務器就可以用自己手里的私鑰解開得到明文。就算中間人拿到了公鑰，那也解不開客戶端用也公鑰加密的密文。所以這樣從客戶端到服務器之間的通信算是安全的（實際也不安全）

我們暫且先不討論實際也不安全的問題

那么服務器到客戶端的通信怎么解決呢？也用非對稱加密一遍就可以啦

方案三：雙方都使用非對稱加密

服務器手上有公鑰 S’ 和私鑰 S ；客戶端手上有公鑰 C’ 和 私鑰 C

1. 開始先互相以明文方式交換公鑰
2. 服務端給客戶端發信息，先用客戶端給的公鑰 C’ 加密之后發送，客戶端收到后用自己手里的私鑰 C 解密
3. 客戶端給服務端發信息，先用服務端給的公鑰 S’ 加密之后發送，服務端收到后用自己手里的私鑰 S 解密

兩個問題：1、效率太低 2、依舊有安全問題

方案四：使用非對稱加密 + 對稱加密

前面的效率問題主要是因為雙方相對方發送數據都要經過非對稱加密解密的過程（前面提到這是它的缺點）

這次我們用下面的方法：

1. 服務器手里有公鑰 S’ 和私鑰 S ；客戶端手上有一個對稱加密的密鑰 C
2. 服務器將公鑰 S’ 發送給客戶端，客戶端用公鑰 S’ 將自己準備好的密鑰 C 加密后發給服務器
3. 服務器收到后用私鑰 S 解密信息，得到對稱加密的密鑰 C
4. 之后雙方就使用這個密鑰 C 進行通信

相當于用非對稱加密的方式保證了對稱加密密鑰傳輸的安全性

因為如果有中間人他只能拿到公鑰 S‘ ，所以解不開客戶端向服務器發送的密文，也就無法得到密鑰 C 那么這種方式看起來似乎是天衣無縫了，實際上還是不安全的。

中間人攻擊

以上情況都有一個假設：中間人不會篡改信息。那如果中間人將服務器的公鑰換成了自己的公鑰呢？

有以下情況：

• 服務器手里有公鑰 S’ 和私鑰 S ；中間人手上有公鑰 M’ 和私鑰 M；客戶端有對稱密鑰 C
• 服務器將公鑰 S’ 發給服務器，但是這時中間人收到了公鑰 S’ 并將 S’ 改成了自己的公鑰 M’ 發給了客戶端
• 客戶端收到了公鑰 M’ （客戶端不知道公鑰有沒有被替換）之后客戶端將自己的密鑰 C 通過公鑰 M’ 加密并發給了服務器
• 這時中間人又從中作梗了：中間人將密文通過自己的私鑰 M 解密得到了密鑰 C ，之后再將密鑰 C 重新用公鑰 S’ 加密后發給服務器
• OK，服務器最終雖然也收到了密鑰 C ，但是中間人也有密鑰 C 呀，它們之間的通信完全暴露在了中間人眼睛下（中間人此時可以劫持，監聽甚至修改數據）

中間人在最開始就攻擊，并且篡改數據，所以方案 二 三 四 都是有這個問題的，本質在于客戶端無法確定自己收到的信息是否來自目標服務器！！！

證書

這個時候就需要有一個"第三方見證人"了：CA認證（Man-in-the-MiddleAttack）

所有服務器在使用HTTPS協議之前都要向CA機構申請一份數字證書，證書里面包含公鑰，服務器將證書發給瀏覽器，瀏覽器直接從證書里面獲取公鑰即可，證書就像身份證，證明服務器公鑰的權威

證書里面包含了以下信息：

• 證書發布機構
• 證書有效期
• 公鑰
• 證書所有者
• 簽名
• …

證書在申請的時候需要在特定平臺審查，并且會同時生成一個密鑰對 即公鑰和私鑰，這個密鑰對就是來進行明文加密以及數字簽名的。其中公鑰會隨著CSR文件一起發送給CA進行權威認證，私鑰服務端自己保留，用來進行后續通信（得到對稱密鑰）

數據簽名

為了防止有人篡改CA證書，CA機構還需要對證書進行簽名，也就是將CA證書的明文數據進行數據摘要（hash）然后用CA機構擁有的私鑰進行加密得到數字簽名（數字簽名是可以被公鑰解密的），在將數字簽名和證書明文一起頒發給服務端

方案五：非對稱加密 + 對稱加密 + 證書認證

1. 如上圖，服務端向機構申請證書，將自己的公鑰 S’ 和私鑰 S 給給CA機構，CA機構審查之后將域名，公鑰 S’ ，簽發機構等信息先用hash形成散列之后再用CA機構自己的私鑰加密形成簽名，之后附帶上明文信息簽發給服務端
2. 服務端收到證書后，與客戶端通信，先將證書給客戶端審查（明文），客戶端收到證書后會先判定證書有效期，證書發布機構是否信任，然后驗證證書是否被篡改：從系統中拿到該證書發布機構的公鑰，對簽名解密得到hash散列，之后將明文用hash散列后對比，如果兩個散列相等，證明證書沒有被篡改
3. 這時客戶端就拿到了服務端的公鑰 S’ （是包含在證書里面的！）之后客戶端用這個密鑰和服務端協商對稱密鑰（對稱加密效率高一點）
4. 協商好對稱密鑰后，雙方后續就用這個對稱密鑰進行加密通信

查看瀏覽器的受信任證書頒發機構

chrome瀏覽器：設置 -> 隱私與安全 -> 管理證書

中間人可能篡改證書嗎？

如果中間人直接篡改證書明文（把服務器的公鑰換成自己的），由于他沒有CA機構的私鑰，所以無法hash之后用私鑰加密形成簽名，就算強行篡改，客戶端收到證書后會發現簽名和解密后的值不一致，客戶端是知道證書被篡改過的，“有內鬼，終止交易”

• 如果中間人直接掉包整個證書？

中間人沒有CA私鑰，無法制作證書（用其他私鑰制作的證書客戶端也解不開，因為客戶端只認受信任的機構也只存儲了受信任機構的公鑰）

所以中間人只能向CA申請真證書，然后用自己申請的真證書進行調包，但是證書中包含了域名，申請者等服務端信息，整體調包后，客戶端發現這不是我想要進行通信的域名也能夠識別出來

中間人沒有CA私鑰，對任何證書都無法合法修改，包括自己申請的證書

為什么要對證書的明文形成hash后還要加密形成簽名？

常見摘要算法：MD5，SHA

**特性：**定長，分散（源字符改變一點得到的hash會有很大變化），不可逆（將hash還原成源字符串幾乎不可能）

所以判斷兩個字符串的hash相等就認為字符串相等

如果不加密用明文傳輸，中間人可以將源字符串篡改后，用同樣的摘要算法再次生成一個摘要覆蓋即可達到欺騙的作用，所以關鍵還是在受信任的機構手中的那一把私鑰上

另外要先形成hash摘要而不直接數據加密的原因是因為可以縮小簽名加密后密文的長度，加快驗證簽名的運算速度

如何成為中間人？

• ARP欺騙

在局域網中，hacker經過收到ARP Request廣播包，能夠偷聽到其它節點的 (IP, MAC)地址。例， 黑客收到兩個主機A, B的地址，告訴B (受害者) ，??是A，使得B在發送給A 的數據包都被黑客截取

• ICMP攻擊

由于ICMP協議中有重定向的報文類型，那么我們就可以偽造?個ICMP信息然后發送給局域網中的客戶端，并偽裝自己是?個更好的路由通路。從而導致目標所有的上網流量都會發送到我們指定的接口上，達到和ARP欺騙同樣的效果

• 假WiFi 假網站

總結

HTTPS工作中涉及到的密鑰有三組：

1. 非對稱加密：用于校驗證書是否被篡改，服務器持有私鑰（私鑰在形成CSR文件與申請證書時獲得），客戶端持有公鑰（操作系統包含了可信任的 CA 認證機構有哪些，同時持有對應的公鑰）服務器在客戶端請求時，返回攜帶簽名的證書，客戶端通過這個公鑰進行證書驗證, 保證證書的合法性，進?步保證證書中攜帶的服務端公鑰權威性
2. 非對稱加密：用于協商生成對稱加密的密鑰，客戶端用收到的CA證書中的公鑰（是可被信任的）給隨機生成的對稱加密的密鑰加密，傳輸給服務器，服務器通過私鑰解密獲取到對稱加密密鑰
3. 對稱加密：客戶端和服務器后續傳輸的數據都通過這個對稱密鑰加密解密（?切的關鍵都是圍繞這個對稱加密的密鑰，其他的機制都是輔助這個密鑰工作的。第二組非對稱加密的密鑰是為了讓客戶端把這個對稱密鑰傳給服務器；第?組非對稱加密的密鑰是為了讓客戶端拿到第二組非對稱加密的公鑰）

附錄：（AI生成）

HTTPS（Hypertext Transfer Protocol Secure）是在 HTTP 基礎上通過 SSL/TLS 協議進行加密的安全傳輸協議，它顯著提升了網絡通信的安全性，但并非絕對安全。其安全性依賴于加密算法、證書管理、協議實現等多個環節，任何一個環節出現漏洞或配置不當，都可能導致安全風險。

一、HTTPS 的核心安全保障

HTTPS 通過以下機制提供安全防護，這也是它被廣泛采用的原因：

1. 傳輸加密：通過 SSL/TLS 協議對傳輸的數據進行加密（對稱加密），防止數據在傳輸過程中被竊聽（如公共 WiFi 中的監聽）。
2. 身份認證：通過數字證書驗證服務器身份，確保用戶訪問的是真實的目標服務器（而非釣魚網站）。
3. 數據完整性：通過哈希算法校驗數據，防止傳輸過程中被篡改（如插入惡意代碼）。

二、HTTPS 的安全局限性（為何不是絕對安全）

盡管 HTTPS 大幅提升了安全性，但以下場景可能導致其防護失效：

1. 證書相關問題

• 偽造或惡意證書：如果攻擊者獲取了可信證書機構（CA）的私鑰，或通過釣魚誘導用戶信任自簽名證書（如在企業內網中強制安裝惡意根證書），可能偽造 HTTPS 網站，實施中間人攻擊。
• 證書配置錯誤：例如證書過期、域名不匹配（如證書為example.com，但實際訪問test.example.com）、未正確配置證書鏈等，可能導致瀏覽器提示風險，甚至被攻擊者利用。
• 弱 CA 信任鏈：部分國家或地區的 CA 管理不嚴格，可能為惡意網站頒發證書，破壞 HTTPS 的身份認證機制。

2. 加密算法與協議漏洞

• 過時的加密算法：如果服務器使用已被破解的加密算法（如 RC4）、弱哈希算法（如 SHA1）或短密鑰（如 RSA 1024 位以下），攻擊者可能通過計算破解加密數據。
• 協議漏洞：歷史上 SSL/TLS 協議曾出現多個高危漏洞，如 Heartbleed（2014 年，利用 TLS 心跳機制泄露內存數據）、POODLE（2014 年，針對 SSLv3 的降級攻擊）、Logjam（2015 年，針對 Diffie-Hellman 密鑰交換的攻擊）等。盡管這些漏洞已通過協議更新修復，但未及時升級的服務器仍可能受影響。

3. 傳輸之外的安全風險

• 服務器端漏洞：HTTPS 僅保護傳輸過程，若服務器本身被入侵（如數據庫泄露、服務器被植入后門），即使傳輸加密，存儲在服務器中的數據（如用戶密碼、個人信息）仍可能被竊取。
• 客戶端漏洞：若用戶設備被植入惡意軟件（如鍵盤記錄器、木馬），攻擊者可直接在數據加密前（客戶端）或解密后（服務器端）獲取信息，繞過 HTTPS 的加密防護。
• 釣魚與社會工程學：攻擊者可能搭建域名相似的 HTTPS 網站（如faceb00k.com模仿facebook.com），利用用戶的疏忽騙取信息。此時 HTTPS 的加密和認證機制雖 “正常工作”，但目標本身是惡意的。

4. 中間人攻擊（MITM）的特殊場景

在某些可控網絡環境中（如企業內網、公共 WiFi 被劫持），攻擊者可通過以下方式實施中間人攻擊：

• 強制用戶設備信任其偽造的根證書，從而解密并篡改 HTTPS 流量（如部分企業的 “上網行為管理” 設備會這樣操作）。
• 利用協議降級攻擊（如誘使客戶端使用不安全的 SSLv3 協議），繞過強加密機制。

三、如何增強 HTTPS 的安全性？

雖然 HTTPS 不是絕對安全，但通過以下措施可大幅降低風險：

• 使用強加密算法（如 AES-256、ECDHE 密鑰交換）和現代 TLS 版本（TLS 1.2 及以上，禁用 SSLv3、TLS 1.0/1.1）。
• 選擇可信的證書機構（CA），定期檢查證書有效性，啟用證書透明度（CT）機制（防止 CA 濫用簽發權限）。
• 服務器端及時更新系統和軟件，修復協議漏洞；客戶端保持操作系統和瀏覽器更新。
• 結合其他安全措施，如網站啟用 HSTS（防止降級到 HTTP）、使用 HTTP Public Key Pinning（HPKP，限制可信證書）等。

總結

HTTPS 是目前網絡傳輸中最可靠的安全協議之一，但其安全性并非 “絕對”，而是依賴于加密算法、證書管理、協議實現等多個環節的有效性。只要存在人為配置失誤、算法漏洞或社會工程學攻擊的可能，HTTPS 的防護就可能被突破。因此，在使用 HTTPS 的同時，還需結合整體安全策略（如服務器加固、用戶安全教育），才能最大限度降低風險。