當前位置: 妍妍網 > 碼農

記住看小電影前一定要檢查網址是不是 HTTPS 的,不然…

2024-07-10碼農

大家好,我是磊哥。

# HTTP 協定

在談論 HTTPS 協定之前,先來回顧一下 HTTP 協定的概念。

1.1 HTTP 協定介紹

HTTP 協定是一種基於文本的傳輸協定,它位於 OSI 網路模型中的套用層。

HTTP 協定是透過客戶端和伺服器的請求應答來進行通訊,目前協定由之前的 RFC 2616 拆分成立六個單獨的協定說明( RFC 7230 RFC 7231 RFC 7232 RFC 7233 RFC 7234 RFC 7235 ),通訊報文如下:

請求

POSThttp://www.baidu.com HTTP/1.1Host: www.baidu.comConnection: keep-aliveContent-Length: 7User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36wd=HTTP

響應

HTTP/1.1 200 OKConnection: Keep-AliveContent-Encoding: gzipContent-Type: text/html;charset=utf-8Date: Thu, 14 Feb 2019 07:23:49 GMTTransfer-Encoding: chunked<html>...</html>

1.2 HTTP 中間人攻擊

HTTP 協定使用起來確實非常的方便,但是它存在一個致命的缺點:不安全。

我們知道 HTTP 協定中的報文都是以明文的方式進行傳輸,不做任何加密,這樣會導致什麽問題呢?下面來舉個例子:

如果你近期準備面試跳槽,建議在ddkk.com線上刷題,涵蓋 一萬+ 道 Java 面試題,幾乎覆蓋了所有主流技術面試題,還有市面上最全的技術五百套,精品系列教程,免費提供。

1.小明在 JAVA 貼吧發帖,內容為我愛JAVA:

2.被中間人進行攻擊,內容修改為我愛PHP

3.小明被群嘲(手動狗頭)

可以看到在 HTTP 傳輸過程中,中間人能看到並且修改 HTTP 通訊中所有的請求和響應內容,所以使用 HTTP 是非常的不安全的。

1.3 防止中間人攻擊

這個時候可能就有人想到了,既然內容是明文那我使用對稱加密的方式將報文加密這樣中間人不就看不到明文了嗎,於是如下改造:

1.雙方約定加密方式

2,使用 AES 加密報文

這樣看似中間人獲取不到明文資訊了,但其實在通訊過程中還是會以明文的方式暴露加密方式和秘鑰,如果第一次通訊被攔截到了,那麽秘鑰就會泄露給中間人,中間人仍然可以解密後續的通訊:

那麽對於這種情況,我們肯定就會考慮能不能將秘鑰進行加密不讓中間人看到呢?答案是有的,采用非對稱加密,我們可以透過 RSA 演算法來實作。

在約定加密方式的時候由伺服器生成一對公私鑰,伺服器將公鑰返回給客戶端,客戶端本地生成一串秘鑰(AES_KEY)用於對稱加密,並透過伺服器發送的公鑰進行加密得到(AES_KEY_SECRET),之後返回給伺服端,伺服端透過私鑰將客戶端發送的AES_KEY_SECRET進行解密得到AEK_KEY,最後客戶端和伺服器透過AEK_KEY進行報文的加密通訊,改造如下:

可以看到這種情況下中間人是竊取不到用於AES加密的秘鑰,所以對於後續的通訊是肯定無法進行解密了,那麽這樣做就是絕對安全了嗎?

所謂道高一尺魔高一丈,中間人為了對應這種加密方法又想出了一個新的破解方案,既然拿不到AES_KEY,那我就把自己模擬成一個客戶端和伺服器端的結合體,在使用者->中間人的過程中中間人模擬伺服器的行為,這樣可以拿到使用者請求的明文,在中間人->伺服器的過程中中間人模擬客戶端行為,這樣可以拿到伺服器響應的明文,以此來進行中間人攻擊:

這一次通訊再次被中間人截獲,中間人自己也偽造了一對公私鑰,並將公鑰發送給使用者以此來竊取客戶端生成的AES_KEY,在拿到AES_KEY之後就能輕松的進行解密了。

中間人這樣為所欲為,就沒有辦法制裁下嗎,當然有啊,接下來我們看看 HTTPS 是怎麽解決通訊安全問題的。

# HTTPS 協定

2.1 HTTPS 簡介

HTTPS 其實是SSL+HTTP的簡稱,當然現在SSL基本已經被TLS取代了,不過接下來我們還是統一以SSL作為簡稱,SSL協定其實不止是套用在HTTP協定上,還在套用在各種套用層協定上,例如:FTP、WebSocket。

其實SSL協定大致就和上一節非對稱加密的性質一樣,握手的過程中主要也是為了交換秘鑰,然後再通訊過程中使用對稱加密進行通訊,大概流程如下:

這裏我只是畫了個示意圖,其實真正的 SSL 握手會比這個復雜的多,但是性質還是差不多,而且我們這裏需要關註的重點在於 HTTPS 是如何防止中間人攻擊的。

透過上圖可以觀察到,伺服器是透過 SSL 證書來傳遞公鑰,客戶端會對 SSL 證書進行驗證,其中證書認證體系就是確保SSL安全的關鍵,接下來我們就來講解下CA 認證體系,看看它是如何防止中間人攻擊的。

2.2 CA 認證體系

上一節我們看到客戶端需要對伺服器返回的 SSL 證書進行校驗,那麽客戶端是如何校驗伺服器 SSL 證書的安全性呢。

權威認證機構

在 CA 認證體系中,所有的證書都是由權威機構來頒發,而權威機構的 CA 證書都是已經在作業系統中內建的,我們把這些證書稱之為CA根證書:

簽發證書

我們的套用伺服器如果想要使用 SSL 的話,需要透過權威認證機構來簽發CA證書,我們將伺服器生成的公鑰和站點相關資訊發送給CA簽發機構,再由CA簽發機構透過伺服器發送的相關資訊用CA簽發機構進行加簽,由此得到我們套用伺服器的證書,證書會對應的生成證書內容的簽名,並將該簽名使用CA簽發機構的私鑰進行加密得到證書指紋,並且與上級證書生成關系鏈。

如果你近期準備面試跳槽,建議在ddkk.com線上刷題,涵蓋 一萬+ 道 Java 面試題,幾乎覆蓋了所有主流技術面試題,還有市面上最全的技術五百套,精品系列教程,免費提供。

這裏我們把百度的證書下載下來看看:

可以看到百度是受信於GlobalSign G2,同樣的GlobalSign G2是受信於GlobalSign R1,當客戶端(瀏覽器)做證書校驗時,會一級一級的向上做檢查,直到最後的根證書,如果沒有問題說明伺服器證書是可以被信任的。

如何驗證伺服器證書

那麽客戶端(瀏覽器)又是如何對伺服器證書做校驗的呢,首先會透過層級關系找到上級證書,透過上級證書裏的公鑰來對伺服器的證書指紋進行解密得到簽名(sign1),再透過簽名演算法算出伺服器證書的簽名(sign2),透過對比sign1和sign2,如果相等就說明證書是沒有被篡改也不是偽造的。

這裏有趣的是,證書校驗用的 RSA 是透過私鑰加密證書簽名,公鑰解密來巧妙的驗證證書有效性。

這樣透過證書的認證體系,我們就可以避免了中間人竊取AES_KEY從而發起攔截和修改 HTTP 通訊的報文。

# 總結

首先先透過對 HTTP 中間人攻擊的來了解到 HTTP 為什麽是不安全的,然後再從安全攻防的技術演變一直到 HTTPS 的原理概括,希望能讓大家對 HTTPS 有個更深刻的了解。

🔥 磊哥私藏精品 熱門推薦 🔥