您好,登錄后才能下訂單哦!
這篇文章主要介紹“HTTPS應(yīng)用實例分析”的相關(guān)知識,小編通過實際案例向大家展示操作過程,操作方法簡單快捷,實用性強,希望這篇“HTTPS應(yīng)用實例分析”文章能幫助大家解決問題。
在談?wù)?HTTPS 協(xié)議之前,先來回顧一下 HTTP 協(xié)議的概念。
HTTP 協(xié)議是一種基于文本的傳輸協(xié)議,它位于 OSI 網(wǎng)絡(luò)模型中的應(yīng)用層
。
HTTP 協(xié)議是通過客戶端和服務(wù)器的請求應(yīng)答來進行通訊,目前協(xié)議由之前的 RFC 2616 拆分成立六個單獨的協(xié)議說明(RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235),通訊報文如下:
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
wd=HTTP
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
<html>...</html>
HTTP 協(xié)議使用起來確實非常的方便,但是它存在一個致命的缺點:不安全
。
我們知道 HTTP 協(xié)議中的報文都是以明文的方式進行傳輸,不做任何加密,這樣會導(dǎo)致什么問題呢?下面來舉個例子:
我愛JAVA
:
我愛PHP
可以看到在 HTTP 傳輸過程中,中間人能看到并且修改 HTTP 通訊中所有的請求和響應(yīng)內(nèi)容,所以使用 HTTP 是非常的不安全的。
這個時候可能就有人想到了,既然內(nèi)容是明文那我使用對稱加密
的方式將報文加密這樣中間人不就看不到明文了嗎,于是如下改造:
這樣看似中間人獲取不到明文信息了,但其實在通訊過程中還是會以明文的方式暴露加密方式和秘鑰,如果第一次通信被攔截到了,那么秘鑰就會泄露給中間人,中間人仍然可以解密后續(xù)的通信:
那么對于這種情況,我們肯定就會考慮能不能將秘鑰進行加密不讓中間人看到呢?答案是有的,采用非對稱加密
,我們可以通過 RSA 算法來實現(xiàn)。
在約定加密方式的時候由服務(wù)器生成一對公私鑰
,服務(wù)器將公鑰
返回給客戶端,客戶端本地生成一串秘鑰(AES_KEY
)用于對稱加密
,并通過服務(wù)器發(fā)送的公鑰
進行加密得到(AES_KEY_SECRET
),之后返回給服務(wù)端,服務(wù)端通過私鑰
將客戶端發(fā)送的AES_KEY_SECRET
進行解密得到AEK_KEY
,最后客戶端和服務(wù)器通過AEK_KEY
進行報文的加密通訊,改造如下:
可以看到這種情況下中間人是竊取不到用于AES加密
的秘鑰,所以對于后續(xù)的通訊是肯定無法進行解密了,那么這樣做就是絕對安全了嗎?
所謂道高一尺魔高一丈,中間人為了對應(yīng)這種加密方法又想出了一個新的破解方案,既然拿不到AES_KEY
,那我就把自己模擬成一個客戶端和服務(wù)器端的結(jié)合體,在用戶->中間人
的過程中中間人模擬服務(wù)器的行為,這樣可以拿到用戶請求的明文,在中間人->服務(wù)器
的過程中中間人模擬客戶端行為,這樣可以拿到服務(wù)器響應(yīng)的明文,以此來進行中間人攻擊:
這一次通信再次被中間人截獲,中間人自己也偽造了一對公私鑰,并將公鑰發(fā)送給用戶以此來竊取客戶端生成的AES_KEY
,在拿到AES_KEY
之后就能輕松的進行解密了。
中間人這樣為所欲為,就沒有辦法制裁下嗎,當然有啊,接下來我們看看 HTTPS 是怎么解決通訊安全問題的。
HTTPS 其實是SSL+HTTP
的簡稱,當然現(xiàn)在SSL
基本已經(jīng)被TLS
取代了,不過接下來我們還是統(tǒng)一以SSL
作為簡稱,SSL
協(xié)議其實不止是應(yīng)用在HTTP
協(xié)議上,還在應(yīng)用在各種應(yīng)用層協(xié)議上,例如:FTP
、WebSocket
。
其實SSL
協(xié)議大致就和上一節(jié)非對稱加密
的性質(zhì)一樣,握手的過程中主要也是為了交換秘鑰,然后再通訊過程中使用對稱加密
進行通訊,大概流程如下:
這里我只是畫了個示意圖,其實真正的 SSL 握手會比這個復(fù)雜的多,但是性質(zhì)還是差不多,而且我們這里需要關(guān)注的重點在于 HTTPS 是如何防止中間人攻擊的。
通過上圖可以觀察到,服務(wù)器是通過 SSL 證書來傳遞公鑰
,客戶端會對 SSL 證書進行驗證,其中證書認證體系就是確保SSL
安全的關(guān)鍵,接下來我們就來講解下CA 認證體系
,看看它是如何防止中間人攻擊的。
上一節(jié)我們看到客戶端需要對服務(wù)器返回的 SSL 證書進行校驗,那么客戶端是如何校驗服務(wù)器 SSL 證書的安全性呢。
權(quán)威認證機構(gòu) 在 CA 認證體系中,所有的證書都是由權(quán)威機構(gòu)來頒發(fā),而權(quán)威機構(gòu)的 CA 證書都是已經(jīng)在操作系統(tǒng)中內(nèi)置的,我們把這些證書稱之為CA根證書
:
簽發(fā)證書
我們的應(yīng)用服務(wù)器如果想要使用 SSL 的話,需要通過權(quán)威認證機構(gòu)來簽發(fā)
CA證書
我們將服務(wù)器生成的公鑰和站點相關(guān)信息發(fā)送給
CA簽發(fā)機構(gòu)
再由
CA簽發(fā)機構(gòu)
通過服務(wù)器發(fā)送的相關(guān)信息用
CA簽發(fā)機構(gòu)
進行加簽,由此得到我們應(yīng)用服務(wù)器的證書,證書會對應(yīng)的生成證書內(nèi)容的
簽名
并將該
簽名
使用
CA簽發(fā)機構(gòu)
的私鑰進行加密得到
證書指紋
并且與上級證書生成關(guān)系鏈。
這里我們把百度的證書下載下來看看:
可以看到百度是受信于GlobalSign G2
,同樣的GlobalSign G2
是受信于GlobalSign R1
,當客戶端(瀏覽器)做證書校驗時,會一級一級的向上做檢查,直到最后的根證書
,如果沒有問題說明服務(wù)器證書
是可以被信任的。
如何驗證服務(wù)器證書 那么客戶端(瀏覽器)又是如何對服務(wù)器證書
做校驗的呢,首先會通過層級關(guān)系找到上級證書,通過上級證書里的公鑰
來對服務(wù)器的證書指紋
進行解密得到簽名(sign1)
,再通過簽名算法算出服務(wù)器證書的簽名(sign2)
,通過對比sign1
和sign2
,如果相等就說明證書是沒有被篡改
也不是偽造
的。
這里有趣的是,證書校驗用的 RSA 是通過私鑰加密證書簽名,公鑰解密來巧妙的驗證證書有效性。
這樣通過證書的認證體系,我們就可以避免了中間人竊取AES_KEY
從而發(fā)起攔截和修改 HTTP 通訊的報文。
關(guān)于“HTTPS應(yīng)用實例分析”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識,可以關(guān)注億速云行業(yè)資訊頻道,小編每天都會為大家更新不同的知識點。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。