本篇摘要

• 本篇文章將從https是什么，為什么需要https角度，基于之前學的http[速戳速通HTTP]認識https，介紹什么是加密等，認識加密的兩種方式：對稱加密和非對稱加密；引出五種不同的通信方加密方式外加滲透證書相關概念！

歡迎拜訪： 點擊進入博主主頁

本篇主題： 速通HTTPS基礎概念

制作日期： 2025.07.28

隸屬專欄： 點擊進入所屬Linux專欄

一· 認識HTTPS

• HTTPS 也是一個應用層協議. 是在 HTTP 協議的基礎上引入了一個加密層，即可以理解成SSL+TLS+HTTP構成！

二· 為何要加密

所以:因為 http的內容是明文傳輸的，明文數據會經過路由器、wifi熱點、通信服務運營商、代理服務器等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊，所以我們才需要對信息進行加密。

• 總之，早期的http在網絡中明文傳遞，是暴露的，能被修改!!!

其中：

• 加密就是把明文(要傳輸的信息)進行一系列變換,生成密文！
• 解密就是把密文再進行一系列變換,還原成明文！

在這個加密和解密的過程中,往往需要一個或者多個中間的數據,輔助進行這個過程,這樣的數據稱為密鑰(正確發音yue 四聲,不過大家平時都讀作yao四聲)！

因此：

HTTPS 就是在 HTTP 的基礎上進行了加密,進一步的來保證用戶的信息安全！

三. 加密方式

3.1 對稱加密

• 采用單鑰密碼系統的加密方法，同一個密鑰可以同時用作信息的加密和解密

常見對稱加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等
特點:算法公開、計算量小、加密速度快、加密效率高！

因此：

我們只需要記住:加密秘鑰和解密秘鑰是同一把,這在某種意義上成為了它的缺點！

• 一個簡單的對稱加密：按位異或:

假設明文a= 1234，密鑰key = 8888則加密a ^ key得到的密文b 為9834,然后針對密文9834再次進行運算b ^key,得到的就是原來的明文1234.(對于字符串的對稱加密也是同理,每一個字符都可以表示成一個數字)當然,按位異或只是最簡單的對稱加密.HTTPS中并不是使用按位異或.

3.2 非對稱加密

• 需要兩個密鑰來進行加密和解密，這兩個密鑰是公開密鑰(public key，簡稱公鑰)和私有密鑰(private key，簡稱私鑰)。

• 常見非對稱加密算法:RSA,DSA,ECDSA。

• 特點:算法強度復雜、安全性依賴于算法與密鑰但是由于其算法復雜，而使得加密解密速度沒有對稱加密解密的速度快。

• 最大的缺點就是運算速度非常慢，比對稱加密要慢很多。

因此：

這里只需要記住公鑰加密只有私鑰解開，私鑰加密只有公鑰解開!

3.3 數據摘要與數據指紋

• 數字指紋(數據摘要),其基本原理是利用單向散列函數(Hash函數)對信息進行運算，生成一串固定長度的數字摘要。數字指紋并不是一種加密機制,但可以用來判斷數據有沒有被篡改。

• 摘要常見算法:有 MD5、SHA1、SHA256、SHA512等，算法把無限的映射成有限，因此可能會有碰撞(兩個不同的信息，算出的摘要相同，但是概率非常低)。

• 摘要特征:和加密算法的區別是，摘要嚴格意義不是加密，因為沒有解密，只不過從摘要很難反推原信息，通常用來進行數據對比，比如數據庫管理使用摘要。

四. HTTPS加密方式

4.1 只使用對稱加密

也就是我們只使用一把秘鑰進行通信：

理想：

實際：

• 這種理想上被中間人截取的也只能是密文，無利用價值，但是服務端和每個客戶端都要有個秘鑰來維護，這樣就比較麻煩，因此一般采取的是先發送秘鑰進行協商，但是這樣就被中間人獲取秘鑰了，因此這種方案是不可行的!

因此就導致了這樣：

4.2 雙方使用一個非對稱加密

• 服務端發送信息前提是先要和瀏覽器協商(把公鑰發給它)然后用私鑰加密，給瀏覽器，這樣信息就暴露了(服務器到瀏覽器的信息暴露)，但是瀏覽器拿到后，進行發送用公鑰加密(只能私鑰解密)，此時無法暴露，服務器就能正常收到信息!

比如：

4.3 雙方都使用非對稱加密

• 交換公鑰，公鑰加密，私鑰解密!

• 它們倆互相交換了公鑰(用于加密)，有沒有可能中間人也用公鑰進行加密然后比如從客戶端發給服務端，這樣服務端也就分不清了或者中間人用自己的公鑰給客戶端，然后進行信息竊取！

總結：

• 因為非對稱加密:效率低，而且還有安全問題!

4.4 非對稱加密+對稱加密

• 也就是服務端先把公鑰給客戶端，客戶端用它進行對稱密鑰加密然后給服務端（中間人無私鑰，無法解密），最后他倆就用這個對稱公鑰進行加密！

過程如圖所示：

• 這樣看似是沒有毛病的，但是有沒有可能中間人把自己的公鑰m給client，然后不就得到了這個被m加密的x了，然后再用s進行加密給服務端這個x，之后s與c用x通信不就被中間人掌握了嗎!

結局就成了這樣：

因此：

• 關鍵問題還是防止中間人攻擊也就是如何確保client收到的公鑰來自server而不是中間人呢?

4.5 兩次非對稱加密與一次對稱加密

引入證書

• 這種方式的前兩次非對稱加密都是為了保證最后一次對稱加密的安全性！

• 證書=簽名+明文

CA認證：

服務端在使用 HTTPS 前，需要向 CA 機構申領一份數字證書，數字證書里含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務端公鑰的權威性!

下面看一下申請證書過程圖：

這里需要記住：

• 簽名只有CA機構能做（因為只有它才有對應私鑰）。
• 簽名和解簽名的秘鑰和服務端的秘鑰不是同一種。
• CA的私鑰由CA使用進行簽名，CA的公鑰由瀏覽器自備進行解簽名驗證。
• 服務端和客戶端通信的時候，客戶端會先請求，此時服務端就去CA機構申請一個證書，這個證書就是保證client拿到的一定是server的公鑰!

證書有沒有可能被篡改

那么此時瀏覽器拿到證書如何核對有沒有在server與client傳播過程中被中間人修改呢?

CA機構在形成證書的時候會拿著私鑰對明文信息散列后的摘要進行加密作為簽名!然后當客戶端收到證書后會拿著CA公鑰對簽名解密拿到的數據和明文信息散列后進行對比;如果相同就證明沒有被修改，拿著公鑰進行傳遞對稱秘鑰!!!被修改了就警告! !! —>保證了client一定拿到server的公鑰!!!

如圖：

但是如果中間人修改server發給client的證書的明文/簽名/或者整體替換呢（中間人如果要想成功傳遞自己的秘鑰必須修改簽名）？

• 修改明文：如果修改了的話，當client拿到證書后會發現不匹配的。

• 修改簽名：中間人沒有ca的私鑰無法對前面修改。

• 整體替換:這里整體替換就必須要ca的嚴格審查，中間人只能按照要求申請新的證書，但是還有域名等等一些信息使得客戶端可以識別到是不是對應服務端!

中間人動機：

• 要么把明文里的公鑰換成自己的。
• 要么換成自己的后然后改簽名讓客戶能夠獲取公鑰。

但是，均行不通！

永遠記住:中間人沒有CA私鑰，所以對任何證書都無法進行合法修改，包括自己的。

因此總結：
中間人無法修改證書和偽造新的證書!

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

因此，它來了！

這里可以理解成:

首先進證書申請+客戶端驗證證書(第一次非對稱加密以及解密);接著就是client拿到對應的server的公鑰，然后進行傳遞接下來進行非對稱加密的秘鑰，服務端然后拿著自己的私鑰進行解密拿到(第二次非對稱加密以及解密);接著就是用這個非對稱秘鑰進行通信了(非對稱加密及解密)!

也就是這樣：

• 注意：這里的易混點是簽名和解簽名只能用CA的私鑰和公鑰;而不是服務器的的私鑰公鑰(過程中服務器會泄露公鑰但私鑰不會泄露)!! !

下面看張更加詳細的圖：

詳細步驟：

• 第一次非對稱加密：用于校驗證書是否被篡改.服務器持有私鑰(私鑰在形成CSR文件與申請證書時獲得),客戶端持有公鑰(操作系統包含了可信任的CA認證機構有哪些,同時持有對應的公鑰).服務器在客戶端請求時，返回攜帶簽名的證書.客戶端通過這個公鑰進行證書驗證,保證證書的合法性，進一步保證證書中攜帶的服務端公鑰權威性。

• 第二次非對稱加密：用于協商生成對稱加密的密鑰.客戶端用收到的CA證書中的公鑰(是可被信任的)給隨機生成的對稱加密的密鑰加密，傳輸給服務器,服務器通過私鑰解密獲取到對稱加密密鑰。

• 對稱加密：客戶端和服務器后續傳輸的數據都通過這個對稱密鑰加密解密。

超詳細大白話敘述過程：

首先服務器拿著相關信息(域名，csr,明文信息等），然后生產對應的私鑰（自己保存），公鑰（交給CA）然后向CA申請證書，ca檢查嚴格審核后，拿著自己的專屬私鑰進行對明文散列后數據簽名，接著交給server，最后server把證書給client，client拿著自己內置信任的CA機構的公鑰容納后進行解密簽名看是否合法（明文散列是否相同，域名等是否匹配），不合格就發出警告（上報，或者瀏覽器阻止用戶訪問等），合格的話就拿到對應服務器的公鑰，自己產生對稱秘鑰，然后發給服務端（中間人稚嫩獲得密文，無法解密），然后服務端解密后，他倆就利用對稱秘鑰進行通信了！

總結：
這一切的目的就是保證這個對稱秘鑰通信的時候是安全的 !

疑問點

1. 為什么要進行簽名加密：

• 如果不簽名的話就是直接證書上的就是明文，那么在客戶端核對前是有可能被中間人修改的，因此是不安全的。

2. 為什么明文不直接加密而是先生成摘要呢：

• 縮小簽名密文的長度,加快數字簽名的驗證簽名的運算速度。

3. 如何成為中間人:

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

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

查看瀏覽器的受信任證書相關信息

• 首先點擊瀏覽器對應設置：
  
• 接下來點擊安全選項：
  
• 可以看到有很多信任的證書，點擊可以看到公鑰等信息：
  

五. 本篇小結

• 通過本篇對HTTPS的基礎認識，建立了大致的了解，知道了它背后的原理等，此次學習雖然是大致的，但是也看到了HTTPS背后的基本原理，為以后對它更加深入的學習奠定了基礎，沖沖沖！

請記住：

今日的懶惰成就明日的墮落！