本篇博客給大家帶來的是網絡原理的知識點, 由于時間有限, 分三天來寫, 本篇為線程第三篇,也是最后一篇.
🐎文章專欄: JavaEE初階
🚀若有問題 評論區見
? 歡迎大家點贊 評論 收藏 分享
如果你不知道分享給誰,那就分享給薯條.
你們的支持是我不斷創作的動力 .

要開心

要快樂

順便進步

1. HTTP是什么

HTTPS 也是一個應用層協議. 是在 HTTP 協議的基礎上引入了一個加密層.
HTTP 協議內容都是按照文本的方式明文傳輸的. 這就導致在傳輸過程中出現一些被篡改的情況.

1.1 臭名昭著的 “運營商劫持”

下載一個天天動聽播放器
未被劫持的效果, 點擊下載按鈕, 就會彈出天天動聽的下載鏈接:

已被劫持的效果,點擊下載按鈕, 就會彈出 QQ 瀏覽器的下載鏈接:

由于我們通過網絡傳輸的任何的數據包都會經過運營商的網絡設備(路由器, 交換機等), 那么運營商的網絡設備就可以解析出你傳輸的數據內容, 并進行篡改.

點擊 “下載按鈕”, 其實就是在給服務器發送了一個 HTTP 請求, 獲取到的 HTTP 響應其實就包含了該APP 的下載鏈接. 運營商劫持之后, 就發現這個請求是要下載天天動聽, 那么就自動的把交給用戶的響應給篡改成 “QQ瀏覽器” 的下載地址了.

不止運營商可以劫持, 其他的 黑客 也可以用類似的手段進行劫持, 來竊取用戶隱私信息, 或者篡改內容.
試想一下, 如果黑客在用戶登陸支付寶的時候獲取到用戶賬戶余額, 甚至獲取到用戶的支付密碼.

在互聯網上, 明文傳輸是比較危險的事情!!!
HTTPS 就是在 HTTP 的基礎上進行了加密, 進一步的來保證用戶的信息安全.

1.2 加密是什么?

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

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

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

計算機領域中的最高榮譽就是以他名字命名的 “圖靈獎” .

2. HTTPS的工作過程

既然要保證數據安全, 就需要進行 “加密”.
網絡傳輸中不再直接傳輸明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整體可以分成兩大類: 對稱加密 和 非對稱加密.

2.1 引入對稱加密

對稱加密其實就是通過同一個 “密鑰” , 把明文加密成密文, 并且也能把密文解密成明文.

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

引入對稱加密之后, 即使數據被截獲, 由于黑客不知道密鑰是啥, 因此就無法進行解密, 也就不知道請求的真實內容是啥了.

但事情沒這么簡單. 服務器同一時刻其實是給很多客戶端提供服務的. 這么多客戶端, 每個?用的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了, 黑客就也能拿到了). 因此服務器就需要維護每個客戶端和每個密鑰之間的關聯關系, 這也是個很麻煩的事情.

如果可以的話, 在客戶端和服務器建立連接的時候, 雙方協商確定這次的密鑰.
那么通信雙方如何傳輸對稱密鑰呢?
顯然, 對稱密鑰不能直接明文傳輸.
如果對密鑰進行對稱加密, 就成了"先有雞還是先有蛋"的問題了. 此時單靠對稱密鑰無法解決加密問題.

2.2 引入非對稱加密

非對稱加密要用到兩個密鑰, 一個叫做 “公鑰”, 一個叫做 “私鑰”.公鑰和私鑰是配對的.
非對稱加密最大的缺點就是運算速度非常慢，比對稱加密要慢很多.

通過公鑰對明文加密, 變成密文
通過私鑰對密文解密, 變成明文
當然也可以反著用
通過私鑰對明文加密, 變成密文
通過公鑰對密文解密, 變成明文

舉個簡單的例子:
A 要給 B 一些重要的文件, 但是 B 可能不在. 于是 A 和 B 提前做出約定:
B 說: 我桌子上有個盒子, 然后我給你一把鎖, 你把文件放盒子里用鎖鎖上, 然后我回頭拿著鑰匙來開鎖取文件.
在這個場景中, 這把鎖就相當于公鑰, 鑰匙就是私鑰. 公鑰給誰都行(不怕泄露), 但是私鑰只有 B 自己持有. 持有私鑰的人才能解密.

由于對稱加密的效率比非對稱加密高很多, 因此只是在開始階段協商對稱密鑰的時候使用非對稱加密, 在確定對稱密鑰之后,使用對稱加密傳輸數據. 這種方式也并非萬無一失.黑客還是可以通過某些方式來偽造公鑰.

2.3 中間人攻擊

黑客可以使用中間人攻擊,獲取到對稱密鑰.

服務器具有非對稱加密算法的公鑰S1，私鑰S2.
中間人具有非對稱加密算法的公鑰M1，私鑰M2.

① 客戶端向服務器發起請求，服務器明文傳送公鑰S1給客戶端.
② 中間人劫持數據報文，提取公鑰S1并保存好，然后將被劫持報文中的公鑰S1替換成為自己的公鑰M1，并將偽造報文發給客戶端.
③ 客戶端收到報文，提取公鑰M1(自己當然不知道公鑰被更換過了)，自己形成對稱秘鑰X，用公鑰M1加密X，形成報文發送給服務器.
④ 中間人劫持后，直接用自己的私鑰M2進行解密，得到通信秘鑰X，再用曾經保存的服務端公鑰S1加密后，將報文推送給服務器.
⑤ 服務器拿到報文，用自己的私鑰S2解密，得到通信秘鑰X.
⑥ 雙方開始采用X進行對稱加密，進行通信。但是一切都在中間人的掌握中，劫持數據，進行竊聽甚至修改，都是可以的.

那又該如何解決這個問題呢?

2.4 引入證書

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

這個 證書 可以理解成是一個結構化的字符串, 里面包含了以下信息:

① 證書發布機構
② 證書有效期
③ 公鑰
④ 證書所有者
⑤ 簽名
…

需要注意的是：申請證書的時候，需要在特定平臺生成，會同時生成一對密鑰對，即公鑰和私鑰。這對密鑰對就是用來在網絡通信中進行明文加密以及數字簽名的。

2.4.1 理解數字簽名

簽名的形成是基于非對稱加密算法的，注意，目前暫時和https沒有關系，不要和https中的公鑰私鑰搞混了.

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

① CA機構擁有對稱加密的私鑰A和公鑰A’.
② CA機構對服務端申請的證書明文數據進行hash，形成數據摘要.
③ 然后對數據摘要用CA私鑰A’加密，得到數字簽名S.
服務端申請的證書明文和數字簽名S 共同組成了數字證書，這樣一份數字證書就可以頒發給服務端了

2.4.2 通過幀數解決中間人攻擊

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

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

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

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

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

中間人能否掉包整個證書？

因為中間人沒有CA私鑰，所以無法制作假的證書.
要想擁有CA私鑰,只能向CA申請真證書，然后用自己申請的證書進行掉包.
這個確實能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務端認證信息，如果整體掉包，客戶端依舊能夠識別出來。
中間人沒有CA私鑰，所以對任何證書都無法進行合法修改.

3. HTTPS加密總結

HTTPS 工作過程中涉及到的密鑰有三組.

第一組(非對稱加密): 用于校驗證書是否被篡改.

第二組(非對稱加密): 用于協商生成對稱加密的密鑰.

第三組(對稱加密): 客戶端和服務器后續傳輸的數據都通過這個對稱密鑰來加密解密.

本篇博客到這里就結束啦, 感謝觀看 ???

🐎期待與你的下一次相遇😊😊😊