[[398974]]

本文轉載自微信公眾號「三分鐘學前端」，作者sisterAn  。轉載本文請聯系三分鐘學前端公眾號。

HTTP 協議

HTTP(Hyper Text Transfer Protocol)協議是超文本傳輸協議的縮寫，它是從WEB服務器傳輸超文本標記語言(HTML)到本地瀏覽器的傳送協議，位于 OSI 網絡模型中的應用層

HTTP 是一個基于TCP/IP通信協議來傳遞數據的協議，傳輸的數據類型為 HTML 文件、圖片文件、查詢結果等。

HTTP協議一般用于 B/S 架構。瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務端即 WEB 服務器發送所有請求。

HTTP 特點

• HTTP 協議支持客戶端/服務端模式，也是一種請求/響應模式的協議
• 簡單快速： 客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST
• 靈活： HTTP允許傳輸任意類型的數據對象。傳輸的類型由Content-Type加以標記。
• 無連接： 限制每次連接只處理一個請求。服務器處理完請求，并收到客戶的應答后，即斷開連接，但是卻不利于客戶端與服務器保持會話連接，為了彌補這種不足，產生了兩項記錄http狀態的技術，一個叫做Cookie,一個叫做Session。
• 無狀態： 無狀態是指協議對于事務處理沒有記憶，后續處理需要前面的信息，則必須重傳。

HTTP 中間人攻擊

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

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

例如：小明 JAVA 貼吧發帖，內容為 我愛JAVA：

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

服務器接收到的就是錯誤的信息：我愛PHP

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

如何防止中間人攻擊

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

對稱加密

對稱加密 很好理解，即加密和解密使用的同一個密鑰，是 對稱 的。只要保證了密鑰的安全，那整個通信過程就可以說具有了機密性。

舉個例子，你想要登錄某網站，只要事先和它約定好使用一個對稱密鑰，通信過程中傳輸的全是用密鑰加密后的密文，只有你和網站才能解密。黑客即使能夠竊聽，看到的也只是亂碼，因為沒有密鑰無法解出明文，所以就實現了機密性。

缺點： 這種加密方式固然很好，但是問題就在于如何讓雙方知道秘鑰，術語叫“密鑰交換”。因為傳輸數據都是走的網絡，如果將秘鑰通過網絡的方式傳遞的話，一旦秘鑰被截獲就沒有加密的意義的。

非對稱加密

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

公鑰和私鑰有個特別的 單向 性，雖然都可以用來加密解密，但公鑰加密后只能用私鑰解密，反過來，私鑰加密后也只能用公鑰解密。

非對稱加密可以解決 密鑰交換 的問題。網站秘密保管私鑰，在網上任意分發公鑰，你想要登錄網站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。而黑客因為沒有私鑰，所以就無法破解密文。

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

簡單流程如下：首先服務端將公鑰公布出去，那么客戶端也就知道公鑰了。接下來客戶端創建一個秘鑰，然后通過公鑰加密并發送給服務端，服務端接收到密文以后通過私鑰解密出正確的秘鑰，這時候兩端就都知道秘鑰是什么了。

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

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

• 在 用戶->中間人 的過程中，中間人模擬服務器的行為 ，這樣可以拿到用戶請求的明文
• 在 中間人->服務器 的過程中中間人模擬客戶端行為，這樣可以拿到服務器響應的明文

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

還是沒有徹底解決中間人攻擊問題，怎么辦喃?接下來我們看看 HTTPS 是怎么解決通訊安全問題的。

HTTPS

HTTPS并非是應用層的一種新協議，其實是 HTTP+SSL/TLS 的簡稱

HTTP 和 HTTPS 的區別：

• HTTP 是超文本傳輸協議，信息是明文傳輸，HTTPS 則是具有安全性的TLS(SSL)加密傳輸協議
• HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443
• HTTP 的連接很簡單，是無狀態的;HTTPS協議是由 HTTP+SSL/TLS 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTPS 協議安全。

SSL/TSL

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

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

HTTPS 通過了 HTTP 來傳輸信息，但是信息通過 TLS 協議進行了加密

TLS 協議位于傳輸層之上，應用層之下。首次進行 TLS 協議傳輸需要兩個 RTT ，接下來可以通過 Session Resumption 減少到一個 RTT

在 TLS 中使用了兩種加密技術，分別為：對稱加密和非對稱加密，內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段：

服務器是通過 SSL 證書來傳遞 公鑰，客戶端會對 SSL 證書進行驗證，其中證書認證體系就是確保 SSL 安全的關鍵，接下來我們就來講解下 CA 認證體系 ，看看它是如何防止中間人攻擊的?

CA 認證體系

權威認證機構

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

簽發證書

我們將服務器生成的公鑰和站點相關信息發送給 CA簽發機構 ，再由CA簽發機構通過服務器發送的相關信息用 CA簽發機構 進行加簽，由此得到我們應用服務器的證書，證書會對應的生成證書內容的 簽名 ，并將該 簽名 使用 CA簽發機構 的私鑰進行加密得到 證書指紋 ，并且與上級證書生成關系鏈。

這里我們把百度的證書下載下來看看：

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

如何驗證服務器證書

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

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

使用 HTTPS 會被抓包嗎?

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

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

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

總結

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

參考：

極客時間：透視HTTP協議

面試官：為什么HTTPS是安全的

來自：https://github.com/Advanced-Frontend/Daily-Interview-Question