本篇內(nèi)容介紹了“為什么說HTTPS比HTTP安全”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
HTTP 協(xié)議
公司專注于為企業(yè)提供網(wǎng)站建設(shè)、做網(wǎng)站、微信公眾號開發(fā)、商城網(wǎng)站定制開發(fā)，微信小程序，軟件按需求定制設(shè)計(jì)等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗(yàn)，我們會仔細(xì)了解各客戶的需求而做出多方面的分析、設(shè)計(jì)、整合，為客戶設(shè)計(jì)出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，創(chuàng)新互聯(lián)更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。
HTTP(Hyper Text Transfer Protocol)協(xié)議是超文本傳輸協(xié)議的縮寫，它是從WEB傳輸超文本標(biāo)記語言(HTML)到本地瀏覽器的傳送協(xié)議，位于 OSI 網(wǎng)絡(luò)模型中的應(yīng)用層
HTTP 是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)的協(xié)議，傳輸?shù)臄?shù)據(jù)類型為 HTML 文件、圖片文件、查詢結(jié)果等。
HTTP協(xié)議一般用于 B/S 架構(gòu)。瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請求。HTTP 特點(diǎn)
HTTP 協(xié)議支持客戶端/服務(wù)端模式，也是一種請求/響應(yīng)模式的協(xié)議
簡單快速： 客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST
靈活： HTTP允許傳輸任意類型的數(shù)據(jù)對象。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
無連接： 限制每次連接只處理一個請求。服務(wù)器處理完請求，并收到客戶的應(yīng)答后，即斷開連接，但是卻不利于客戶端與服務(wù)器保持會話連接，為了彌補(bǔ)這種不足，產(chǎn)生了兩項(xiàng)記錄http狀態(tài)的技術(shù)，一個叫做Cookie,一個叫做Session。
無狀態(tài)： 無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶，后續(xù)處理需要前面的信息，則必須重傳。HTTP 中間人攻擊
HTTP 協(xié)議使用起來確實(shí)非常的方便，但是它存在一個致命的缺點(diǎn)：不安全。
我們知道 HTTP 協(xié)議中的報文都是以明文的方式進(jìn)行傳輸，不做任何加密，這樣會導(dǎo)致中間人攻擊
例如：小明 JAVA 貼吧發(fā)帖，內(nèi)容為 我愛JAVA：
被中間人進(jìn)行攻擊，內(nèi)容修改為 我愛PHP
服務(wù)器接收到的就是錯誤的信息：我愛PHP
除此之外，請求信息也容易被竊聽截取、冒充如何防止中間人攻擊
既然 HTTP 是明文傳輸，那我們家加密不就好了
對稱加密
對稱加密 很好理解，即加密和解密使用的同一個密鑰，是 對稱 的。只要保證了密鑰的安全，那整個通信過程就可以說具有了機(jī)密性。
舉個例子，你想要登錄某網(wǎng)站，只要事先和它約定好使用一個對稱密鑰，通信過程中傳輸?shù)娜怯妹荑€加密后的密文，只有你和網(wǎng)站才能解密。黑客即使能夠竊聽，看到的也只是亂碼，因?yàn)闆]有密鑰無法解出明文，所以就實(shí)現(xiàn)了機(jī)密性。
缺點(diǎn)： 這種加密方式固然很好，但是問題就在于如何讓雙方知道秘鑰，術(shù)語叫“密鑰交換”。因?yàn)閭鬏敂?shù)據(jù)都是走的網(wǎng)絡(luò)，如果將秘鑰通過網(wǎng)絡(luò)的方式傳遞的話，一旦秘鑰被截獲就沒有加密的意義的。
非對稱加密
也叫公鑰加密算法，它有兩個密鑰，一個叫 公鑰(public key)，一個叫 私鑰(private key)。兩個密鑰是不同的，不對稱，公鑰可以公開給任何人使用，而私鑰必須嚴(yán)格保密。
公鑰和私鑰有個特別的 單向 性，雖然都可以用來加密解密，但公鑰加密后只能用私鑰解密，反過來，私鑰加密后也只能用公鑰解密。
非對稱加密可以解決 密鑰交換 的問題。網(wǎng)站秘密保管私鑰，在網(wǎng)上任意分發(fā)公鑰，你想要登錄網(wǎng)站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。而黑客因?yàn)闆]有私鑰，所以就無法破解密文。
這種加密方式就可以完美解決對稱加密存在的問題。假設(shè)現(xiàn)在兩端需要使用對稱加密，那么在這之前，可以先使用非對稱加密交換秘鑰。
簡單流程如下：首先服務(wù)端將公鑰公布出去，那么客戶端也就知道公鑰了。接下來客戶端創(chuàng)建一個秘鑰，然后通過公鑰加密并發(fā)送給服務(wù)端，服務(wù)端接收到密文以后通過私鑰解密出正確的秘鑰，這時候兩端就都知道秘鑰是什么了。
那么這樣做就是絕對安全了嗎?
中間人為了對應(yīng)這種加密方法又想出了一個新的破解方案，既然拿不到 私鑰 ，我就把自己模擬成一個客戶端和服務(wù)器端的結(jié)合體，
在 用戶->中間人 的過程中，中間人模擬服務(wù)器的行為 ，這樣可以拿到用戶請求的明文
在 中間人->服務(wù)器 的過程中中間人模擬客戶端行為，這樣可以拿到服務(wù)器響應(yīng)的明文
這一次通信再次被中間人截獲，中間人自己也偽造了一對公私鑰，并將公鑰發(fā)送給用戶以此來竊取客戶端生成的 私鑰 ，在拿到 私鑰 之后就能輕松的進(jìn)行解密了。
還是沒有徹底解決中間人攻擊問題，怎么辦喃?接下來我們看看 HTTPS 是怎么解決通訊安全問題的。HTTPS
HTTPS并非是應(yīng)用層的一種新協(xié)議，其實(shí)是 HTTP+SSL/TLS 的簡稱
HTTP 和 HTTPS 的區(qū)別：
HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的TLS(SSL)加密傳輸協(xié)議
HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443
HTTP 的連接很簡單，是無狀態(tài)的;HTTPS協(xié)議是由 HTTP+SSL/TLS 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTPS 協(xié)議安全。
SSL/TSL
SSL 即安全套接層(Secure Sockets Layer)，在 OSI 模型中處于第 5 層(會話層)，SSL 發(fā)展到 v3 時改名為 TLS(傳輸層安全，Transport Layer Security)，正式標(biāo)準(zhǔn)化，版本號從 1.0 重新算起，所以 TLS1.0 實(shí)際上就是 SSL v3.1。
到今天 TLS 已經(jīng)發(fā)展出了三個版本，分別是 2006 年的 1.1、2008 年的 1.2 和去年(2018)的 1.3。1.2 版本用的最廣泛
HTTPS 通過了 HTTP 來傳輸信息，但是信息通過 TLS 協(xié)議進(jìn)行了加密
TLS 協(xié)議位于傳輸層之上，應(yīng)用層之下。首次進(jìn)行 TLS 協(xié)議傳輸需要兩個 RTT ，接下來可以通過 Session Resumption 減少到一個 RTT
在 TLS 中使用了兩種加密技術(shù)，分別為：對稱加密和非對稱加密，內(nèi)容傳輸?shù)募用苌鲜褂玫氖菍ΨQ加密，非對稱加密只作用在證書驗(yàn)證階段：
服務(wù)器是通過 SSL 證書來傳遞 公鑰，客戶端會對 SSL 證書進(jìn)行驗(yàn)證，其中證書認(rèn)證體系就是確保 SSL 安全的關(guān)鍵，接下來我們就來講解下 CA 認(rèn)證體系 ，看看它是如何防止中間人攻擊的?
CA 認(rèn)證體系
權(quán)威認(rèn)證機(jī)構(gòu)
在 CA 認(rèn)證體系中，所有的證書都是由權(quán)威機(jī)構(gòu)來頒發(fā)，而權(quán)威機(jī)構(gòu)的 CA 證書都是已經(jīng)在操作系統(tǒng)中內(nèi)置的，我們把這些證書稱之為CA根證書
簽發(fā)證書
我們將服務(wù)器生成的公鑰和站點(diǎn)相關(guān)信息發(fā)送給 CA簽發(fā)機(jī)構(gòu) ，再由CA簽發(fā)機(jī)構(gòu)通過服務(wù)器發(fā)送的相關(guān)信息用 CA簽發(fā)機(jī)構(gòu) 進(jìn)行加簽，由此得到我們應(yīng)用服務(wù)器的證書，證書會對應(yīng)的生成證書內(nèi)容的 簽名 ，并將該 簽名 使用 CA簽發(fā)機(jī)構(gòu) 的私鑰進(jìn)行加密得到 證書指紋 ，并且與上級證書生成關(guān)系鏈。
這里我們把百度的證書下載下來看看：
可以看到百度是受信于 GlobalSign G2，同樣的 GlobalSign G2 是受信于GlobalSign R1 ，當(dāng)客戶端(瀏覽器)做證書校驗(yàn)時，會一級一級的向上做檢查，直到最后的 根證書 ，如果沒有問題說明服務(wù)器證書是可以被信任的。
如何驗(yàn)證服務(wù)器證書
那么客戶端(瀏覽器)又是如何對 服務(wù)器證書 做校驗(yàn)的呢，首先會通過層級關(guān)系找到上級證書，通過上級證書里的 公鑰 來對服務(wù)器的 證書指紋 進(jìn)行解密得到簽名(sign1) ，再通過簽名算法算出服務(wù)器證書的 簽名(sign2) ，通過對比 sign1 和 sign2 ，如果相等就說明證書是沒有被篡改也不是偽造的。
這樣通過證書的認(rèn)證體系，我們就可以避免了中間人攻擊從而發(fā)起攔截和修改 HTTP 通訊的報文。使用 HTTPS 會被抓包嗎?
HTTPS 的數(shù)據(jù)是加密的，常規(guī)下抓包工具代理請求后抓到的包內(nèi)容是加密狀態(tài)，無法直接查看。
但是，正如前文所說，瀏覽器只會提示安全風(fēng)險，如果用戶授權(quán)仍然可以繼續(xù)訪問網(wǎng)站，完成請求。因此，只要客戶端是我們自己的終端，我們授權(quán)的情況下，便可以組建中間人網(wǎng)絡(luò)，而抓包工具便是作為中間人的代理。通常 HTTPS 抓包工具的使用方法是會生成一個證書，用戶需要手動把證書安裝到客戶端中，然后終端發(fā)起的所有請求通過該證書完成與抓包工具的交互，然后抓包工具再轉(zhuǎn)發(fā)請求到服務(wù)器，最后把服務(wù)器返回的結(jié)果在控制臺輸出后再返回給終端，從而完成整個請求的閉環(huán)。
既然 HTTPS 不能防抓包，那 HTTPS 有什么意義?HTTPS 可以防止用戶在不知情的情況下通信鏈路被監(jiān)聽，對于主動授信的抓包操作是不提供防護(hù)的，因?yàn)檫@個場景用戶是已經(jīng)對風(fēng)險知情。要防止被抓包，需要采用應(yīng)用級的安全防護(hù)，例如采用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地算法被破解。總結(jié)
我們由 HTTP 中間人攻擊的來了解到 HTTP 為什么是不安全的，然后再從安全攻防談到 HTTPS 的原理概括，最后談一下 HTTPS 抓包問題，希望能讓大家對 HTTPS 有個更深刻的了解。
重慶分公司
重慶分公司
