為什么說(shuō)HTTPS比HTTP安全

本篇內容介紹了“為什么說(shuō)HTTPS比HTTP安全”的有關(guān)知識，在實(shí)際案例的操作過(guò)程中，不少人都會(huì )遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學(xué)有所成！

HTTP 協(xié)議

HTTP(Hyper Text Transfer  Protocol)協(xié)議是超文本傳輸協(xié)議的縮寫(xiě)，它是從WEB傳輸超文本標記語(yǔ)言(HTML)到本地瀏覽器的傳送協(xié)議，位于 OSI 網(wǎng)絡(luò )模型中的應用層

HTTP 是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數據的協(xié)議，傳輸的數據類(lèi)型為 HTML 文件、圖片文件、查詢(xún)結果等。

HTTP協(xié)議一般用于 B/S 架構。瀏覽器作為 HTTP 客戶(hù)端通過(guò) URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請求。

HTTP 特點(diǎn)

• HTTP 協(xié)議支持客戶(hù)端/服務(wù)端模式，也是一種請求/響應模式的協(xié)議

• 簡(jiǎn)單快速： 客戶(hù)向服務(wù)器請求服務(wù)時(shí)，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST

• 靈活： HTTP允許傳輸任意類(lèi)型的數據對象。傳輸的類(lèi)型由Content-Type加以標記。

• 無(wú)連接：  限制每次連接只處理一個(gè)請求。服務(wù)器處理完請求，并收到客戶(hù)的應答后，即斷開(kāi)連接，但是卻不利于客戶(hù)端與服務(wù)器保持會(huì )話(huà)連接，為了彌補這種不足，產(chǎn)生了兩項記錄http狀態(tài)的技術(shù)，一個(gè)叫做Cookie,一個(gè)叫做Session。

• 無(wú)狀態(tài)： 無(wú)狀態(tài)是指協(xié)議對于事務(wù)處理沒(méi)有記憶，后續處理需要前面的信息，則必須重傳。

HTTP 中間人攻擊

HTTP 協(xié)議使用起來(lái)確實(shí)非常的方便，但是它存在一個(gè)致命的缺點(diǎn)：不安全。

我們知道 HTTP 協(xié)議中的報文都是以明文的方式進(jìn)行傳輸，不做任何加密，這樣會(huì )導致中間人攻擊

例如：小明 JAVA 貼吧發(fā)帖，內容為 我愛(ài)JAVA：

被中間人進(jìn)行攻擊，內容修改為 我愛(ài)PHP

服務(wù)器接收到的就是錯誤的信息：我愛(ài)PHP

除此之外，請求信息也容易被竊聽(tīng)截取、冒充

如何防止中間人攻擊

既然 HTTP 是明文傳輸，那我們家加密不就好了

對稱(chēng)加密

對稱(chēng)加密 很好理解，即加密和解密使用的同一個(gè)密鑰，是 對稱(chēng) 的。只要保證了密鑰的安全，那整個(gè)通信過(guò)程就可以說(shuō)具有了機密性。

舉個(gè)例子，你想要登錄某網(wǎng)站，只要事先和它約定好使用一個(gè)對稱(chēng)密鑰，通信過(guò)程中傳輸的全是用密鑰加密后的密文，只有你和網(wǎng)站才能解密。黑客即使能夠竊聽(tīng)，看到的也只是亂碼，因為沒(méi)有密鑰無(wú)法解出明文，所以就實(shí)現了機密性。

缺點(diǎn)：  這種加密方式固然很好，但是問(wèn)題就在于如何讓雙方知道秘鑰，術(shù)語(yǔ)叫“密鑰交換”。因為傳輸數據都是走的網(wǎng)絡(luò )，如果將秘鑰通過(guò)網(wǎng)絡(luò )的方式傳遞的話(huà)，一旦秘鑰被截獲就沒(méi)有加密的意義的。

非對稱(chēng)加密

也叫公鑰加密算法，它有兩個(gè)密鑰，一個(gè)叫 公鑰(public key)，一個(gè)叫 私鑰(private  key)。兩個(gè)密鑰是不同的，不對稱(chēng)，公鑰可以公開(kāi)給任何人使用，而私鑰必須嚴格保密。

公鑰和私鑰有個(gè)特別的 單向 性，雖然都可以用來(lái)加密解密，但公鑰加密后只能用私鑰解密，反過(guò)來(lái)，私鑰加密后也只能用公鑰解密。

非對稱(chēng)加密可以解決 密鑰交換  的問(wèn)題。網(wǎng)站秘密保管私鑰，在網(wǎng)上任意分發(fā)公鑰，你想要登錄網(wǎng)站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。而黑客因為沒(méi)有私鑰，所以就無(wú)法破解密文。

這種加密方式就可以完美解決對稱(chēng)加密存在的問(wèn)題。假設現在兩端需要使用對稱(chēng)加密，那么在這之前，可以先使用非對稱(chēng)加密交換秘鑰。

簡(jiǎn)單流程如下：首先服務(wù)端將公鑰公布出去，那么客戶(hù)端也就知道公鑰了。接下來(lái)客戶(hù)端創(chuàng )建一個(gè)秘鑰，然后通過(guò)公鑰加密并發(fā)送給服務(wù)端，服務(wù)端接收到密文以后通過(guò)私鑰解密出正確的秘鑰，這時(shí)候兩端就都知道秘鑰是什么了。

那么這樣做就是絕對安全了嗎?

中間人為了對應這種加密方法又想出了一個(gè)新的破解方案，既然拿不到 私鑰 ，我就把自己模擬成一個(gè)客戶(hù)端和服務(wù)器端的結合體，

• 在 用戶(hù)->中間人 的過(guò)程中，中間人模擬服務(wù)器的行為 ，這樣可以拿到用戶(hù)請求的明文

• 在 中間人->服務(wù)器 的過(guò)程中中間人模擬客戶(hù)端行為，這樣可以拿到服務(wù)器響應的明文

這一次通信再次被中間人截獲，中間人自己也偽造了一對公私鑰，并將公鑰發(fā)送給用戶(hù)以此來(lái)竊取客戶(hù)端生成的 私鑰 ，在拿到 私鑰  之后就能輕松的進(jìn)行解密了。

還是沒(méi)有徹底解決中間人攻擊問(wèn)題，怎么辦喃?接下來(lái)我們看看 HTTPS 是怎么解決通訊安全問(wèn)題的。

HTTPS

HTTPS并非是應用層的一種新協(xié)議，其實(shí)是 HTTP+SSL/TLS 的簡(jiǎn)稱(chēng)

HTTP 和 HTTPS 的區別：

• HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的TLS(SSL)加密傳輸協(xié)議

• HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443

• HTTP 的連接很簡(jiǎn)單，是無(wú)狀態(tài)的;HTTPS協(xié)議是由 HTTP+SSL/TLS 協(xié)議構建的可進(jìn)行加密傳輸、身份認證的網(wǎng)絡(luò )協(xié)議，比 HTTPS  協(xié)議安全。

SSL/TSL

SSL 即安全套接層(Secure Sockets Layer)，在 OSI 模型中處于第 5 層(會(huì )話(huà)層)，SSL 發(fā)展到 v3 時(shí)改名為  TLS(傳輸層安全，Transport Layer Security)，正式標準化，版本號從 1.0 重新算起，所以 TLS1.0 實(shí)際上就是 SSL  v3.1。

到今天 TLS 已經(jīng)發(fā)展出了三個(gè)版本，分別是 2006 年的 1.1、2008 年的 1.2 和去年(2018)的 1.3。1.2 版本用的最廣泛

HTTPS 通過(guò)了 HTTP 來(lái)傳輸信息，但是信息通過(guò) TLS 協(xié)議進(jìn)行了加密

TLS 協(xié)議位于傳輸層之上，應用層之下。首次進(jìn)行 TLS 協(xié)議傳輸需要兩個(gè) RTT ，接下來(lái)可以通過(guò) Session Resumption 減少到一個(gè)  RTT

在 TLS 中使用了兩種加密技術(shù)，分別為：對稱(chēng)加密和非對稱(chēng)加密，內容傳輸的加密上使用的是對稱(chēng)加密，非對稱(chēng)加密只作用在ssl/' target='_blank'>證書(shū)驗證階段：

服務(wù)器是通過(guò) SSL 證書(shū)來(lái)傳遞 公鑰，客戶(hù)端會(huì )對 SSL 證書(shū)進(jìn)行驗證，其中證書(shū)認證體系就是確保 SSL 安全的關(guān)鍵，接下來(lái)我們就來(lái)講解下 CA  認證體系 ，看看它是如何防止中間人攻擊的?

CA 認證體系

權威認證機構

在 CA 認證體系中，所有的證書(shū)都是由權威機構來(lái)頒發(fā)，而權威機構的 CA 證書(shū)都是已經(jīng)在操作系統中內置的，我們把這些證書(shū)稱(chēng)之為CA根證書(shū)

簽發(fā)證書(shū)

我們將服務(wù)器生成的公鑰和站點(diǎn)相關(guān)信息發(fā)送給 CA簽發(fā)機構 ，再由CA簽發(fā)機構通過(guò)服務(wù)器發(fā)送的相關(guān)信息用 CA簽發(fā)機構  進(jìn)行加簽，由此得到我們應用服務(wù)器的證書(shū)，證書(shū)會(huì )對應的生成證書(shū)內容的 簽名 ，并將該 簽名 使用 CA簽發(fā)機構 的私鑰進(jìn)行加密得到 證書(shū)指紋  ，并且與上級證書(shū)生成關(guān)系鏈。

這里我們把百度的證書(shū)下載下來(lái)看看：

可以看到百度是受信于 GlobalSign G2，同樣的 GlobalSign G2 是受信于GlobalSign R1  ，當客戶(hù)端(瀏覽器)做證書(shū)校驗時(shí)，會(huì )一級一級的向上做檢查，直到最后的 根證書(shū) ，如果沒(méi)有問(wèn)題說(shuō)明服務(wù)器證書(shū)是可以被信任的。

如何驗證服務(wù)器證書(shū)

那么客戶(hù)端(瀏覽器)又是如何對 服務(wù)器證書(shū) 做校驗的呢，首先會(huì )通過(guò)層級關(guān)系找到上級證書(shū)，通過(guò)上級證書(shū)里的 公鑰 來(lái)對服務(wù)器的 證書(shū)指紋  進(jìn)行解密得到簽名(sign1) ，再通過(guò)簽名算法算出服務(wù)器證書(shū)的 簽名(sign2) ，通過(guò)對比 sign1 和 sign2  ，如果相等就說(shuō)明證書(shū)是沒(méi)有被篡改也不是偽造的。

這樣通過(guò)證書(shū)的認證體系，我們就可以避免了中間人攻擊從而發(fā)起攔截和修改 HTTP 通訊的報文。

使用 HTTPS 會(huì )被抓包嗎?

HTTPS 的數據是加密的，常規下抓包工具代理請求后抓到的包內容是加密狀態(tài)，無(wú)法直接查看。

但是，正如前文所說(shuō)，瀏覽器只會(huì )提示安全風(fēng)險，如果用戶(hù)授權仍然可以繼續訪(fǎng)問(wèn)網(wǎng)站，完成請求。因此，只要客戶(hù)端是我們自己的終端，我們授權的情況下，便可以組建中間人網(wǎng)絡(luò )，而抓包工具便是作為中間人的代理。通常  HTTPS  抓包工具的使用方法是會(huì )生成一個(gè)證書(shū)，用戶(hù)需要手動(dòng)把證書(shū)安裝到客戶(hù)端中，然后終端發(fā)起的所有請求通過(guò)該證書(shū)完成與抓包工具的交互，然后抓包工具再轉發(fā)請求到服務(wù)器，最后把服務(wù)器返回的結果在控制臺輸出后再返回給終端，從而完成整個(gè)請求的閉環(huán)。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意義?HTTPS  可以防止用戶(hù)在不知情的情況下通信鏈路被監聽(tīng)，對于主動(dòng)授信的抓包操作是不提供防護的，因為這個(gè)場(chǎng)景用戶(hù)是已經(jīng)對風(fēng)險知情。要防止被抓包，需要采用應用級的安全防護，例如采用私有的對稱(chēng)加密，同時(shí)做好移動(dòng)端的防反編譯加固，防止本地算法被破解。

總結

我們由 HTTP 中間人攻擊的來(lái)了解到 HTTP 為什么是不安全的，然后再從安全攻防談到 HTTPS 的原理概括，最后談一下 HTTPS  抓包問(wèn)題，希望能讓大家對 HTTPS 有個(gè)更深刻的了解。