HTTPS 是如何運作的？它解決了什么問題？-每日消息

來源：SH的全棧筆記

首先，HTTPS 并不是一個新的協(xié)議，而是 HTTP + SSL/TLS，即 SSL（Security SocketLayer）和 TLS（TransportLayerSecurity) 的縮寫。但其實作為 SSL 的繼任者，TLS 已經(jīng)完全替代了 SSL，只是大概還是習慣使用 SSL 這個名詞。為了嚴謹，后續(xù)都會繼續(xù)使用 TLS。


(資料圖片)

簡單了解 HTTP從何而來

要了解 HTTPS，自然我們要先了解 HTTP 協(xié)議，最初 HTTP 協(xié)議的出現(xiàn)是為了讓全球的研究者知識共享而發(fā)明出來的，它于 1990 年被發(fā)明出來，但這一版本的 HTTP 協(xié)議并沒有作為標準。

HTTP/0.9

Tim Berners-Lee 和他的團隊提出這個最早的 HTTP/0.9 版本存在一些不明確的地方，例如：

沒有版本標識，不像現(xiàn)在我們有 HTTP/0.9、HTTP/1.0、HTTP/1.1 等等，就連這個 0.9 都是后面才加上的沒有請求頭，只有一個簡簡單單普普通通的 GET 請求響應只支持 HTML 文檔本身，不支持其他的格式，比如圖片、視頻沒有狀態(tài)碼，根本不知道請求是否成功，或者是因為什么原因失敗短連接，也是就是后面 HTTP/1.1 和部分的 HTTP/1.0 提出 Keep-Alive 要解決的問題

這就是最初的 HTTP，存在很多的缺陷，也難怪沒有成為標準。

HTTP/1.0

到了1996年5月，HTTP 提出了新的版本 HTTP/1.0，而它也成了 HTTP 第一個正式的版本，也被正式的標準化。它解決了 HTTP/0.9 沒有解決的問題，例如：

引入了明確的版本號定義了請求頭、響應頭，這讓請求中能夠附件傳輸很多的元數(shù)據(jù)，這些頭都是基礎，不再贅述支持了多種數(shù)據(jù)類型，例如圖片、音頻、視頻引入了狀態(tài)碼引入了緩存機制

我們現(xiàn)在之后后續(xù)的主流版本其實是 HTTP/1.1，這說明當時提出的 HTTP/1.0 其實還是存在部分的問題。

HTTP/1.1

1997年1月，HTTP/1.1 發(fā)布，這也是在 HTTP/2.0 出來之前最為主流的版本，我們來看看它解決了什么問題就知道 HTTP/1.0 存在的缺陷了。

引入了持久化連接機制基于 Keep-Alive 長連接，推出了管線化技術(shù)，提高了發(fā)送請求的速度引入了更加靈活的緩存機制分塊傳輸范圍請求

所謂持久化連接機制，即服用底層的 TCP 連接。HTTP 底層通信使用的是 TCP，在 HTTP/1.1 之前都是發(fā)起一個 HTTP 請求就會建立一個 TCP 連接，傳輸數(shù)據(jù)之后再斷開。這波操作在 HTTP/1.0 那個時間是沒問題的，HTTP 沒普及，傳輸?shù)膬?nèi)容也都是小容量的文本。但隨著 HTTP 的普及，傳輸?shù)膬?nèi)容變得也越來越來豐富，況且還新增了圖片、音視頻。像這樣頻繁的發(fā)起、斷開 TCP 連接會大大的增加頁面資源的加載速度，降低用戶的體驗。所謂持久化連接也就是，只要任意一方?jīng)]有提出斷開 TCP 連接，就繼續(xù)復用這個連接，減少了創(chuàng)建連接帶來的開銷。

而管線化技術(shù)則是發(fā)送一個請求不用等待其響應，繼續(xù)發(fā)送下一個請求。沒有管線化技術(shù)時，必須等待上一個請求響應回來之后才能發(fā)送下一個請求，而這種機制在網(wǎng)絡較慢的情況下會引發(fā)一個問題——隊頭阻塞。比如，請求一張較大的圖片，偏偏網(wǎng)絡還慢，那么后續(xù)的請求都會被阻塞。但管線化技術(shù)解決了這個問題嗎？解決了一部分，沒有完全解決。采用管線化技術(shù)，請求雖然發(fā)出去了，但它是有序的， 所以在等待響應時，這一批里有響應遲遲沒有回來，后續(xù)的請求仍然要等待。所以這個問題并沒有完全解決。

HTTP/2.0

既然有問題，那么后續(xù)就需要有新的版本來解決這些問題。2015年5月，HTTP/2.0 正式標準化，之后慢慢開始大面積的普及，那么它又解決了哪些問題呢？主要如下：

提出了多路復用，解決了 HTTP/1.1 中的隊頭阻塞問題使用了二進制協(xié)議，而不是原來的文本協(xié)議對頭部進行壓縮，減少每個 HTTP 請求的頭部大小，減少了傳輸?shù)臄?shù)據(jù)大小支持服務器推送，HTTP/2.0 允許服務器主動推送資源到客戶端，減少客戶端的請求次數(shù)

當然，相信你也知道，現(xiàn)在 HTTP/3.0 也出來了，其關鍵的改動在于將底層傳輸層的協(xié)議從 TCP 切換到了QUIC，其底層采用的是 UDP，這個后面有機會單獨寫一篇文章來介紹。

Why HTTPS？

HTTP 即使推出了很多個版本，但是仍然存在問題，例如：

協(xié)議本身沒有加密，再加上底層使用的 TCP/IP 本身就在很多環(huán)節(jié)容易被竊聽，例如我們熟悉的 Wireshark沒有驗證通信方的身份，可能遭遇偽裝無法校驗數(shù)據(jù)是否被篡改混合加密

所以這才有了 HTTPS，也就是 HTTP + TLS。

在 HTTP 協(xié)議中，由它本身直接和 HTTP 通信，而在 HTTPS 協(xié)議中，HTTP 是和 TLS 進行通信，相當于給套了一層娃，加了個中間層。

那要如何進行加密呢？

HTTPS 采用了混合加密的方式，大致的流程如下：

客戶端訪問服務器，服務器會返回自己的公鑰客戶端生成一個隨機密鑰，使用上一步獲取的公鑰對隨機密鑰進行加密將用服務器公鑰加密后的客戶端隨機密鑰發(fā)送給服務器服務器用自己的私鑰進行解密，拿到客戶端的隨機密鑰明文

到這里，客戶端和瀏覽器就將后續(xù)通信加解密要使用到的密鑰安全的進行了傳輸，后續(xù)客戶端服務器的所有通信都會使用這個隨機密鑰。所謂的混合加密就是即使用了對稱加密，也使用了非對稱加密。

中間人攻擊

但是這個步驟有個比較明顯的問題，即——中間人攻擊。

還是基于上面的這個步驟，客戶端以為自己在和服務器通信，實際上它在和中間人通信，然后中間人將服務器的真正公鑰 S 保存了下來，然后把中間人自己的公鑰 B 返回給了客戶端。

客戶端拿到了中間人的公鑰 B，然后使用公鑰 B 對其生成的隨機密鑰進行加密，然后傳給中間人。中間人拿到了加密密文，使用自己的私鑰 B’ 進行解密，到這里就拿到了客戶端的隨機密鑰。然后再用保存好的服務器真正公鑰 S 加密，將密文再傳給服務器。其流程如下圖所示：

中間人攻擊示意圖

這樣就完成了一波套娃，并且客戶端和服務器都沒有感知。這樣一來，一旦攻擊成功，后續(xù)的通信中間人都能夠通過前面步驟拿到的隨機密鑰進行解密，然后篡改，再加密傳給服務器。

那該如何解決這個問題呢？

在上面的流程中，其關鍵的問題在于客戶端無法證明服務器返回的公鑰的正確性，它可能是中間人的公鑰，而不是服務器的。如果有某種方式能夠讓我們確認，這個公鑰的的確確就是服務器的真實公鑰，上面的問題就迎刃而解了。

而這就是 CA。

CA 證書

全稱為CertificateAuthority，它是一個機構(gòu)，可以將其理解為客戶端和服務器都可以信賴的一個第三方。開發(fā)人員會將服務器的真實公鑰提供給 CA，然后 CA 判斷服務器的身份之后，會對公鑰簽名，然后將其和 CA 證書綁定在一起。當然 CA 證書包含的不僅僅只有簽名，還有序列號、用途、頒發(fā)者、有效時間之類的。

然后客戶端來請求公鑰時，服務器會直接把證書返回給客戶端。那么問題又來了，你怎么能夠保證返回的證書不是由中間人返回的？加了個 CA 就能夠解決這個問題嗎？

當然不是。

客戶端還會對 CA 證書進行校驗，以此來保證：

CA 機構(gòu)值得信賴服務器的公鑰真實有效

否則仍然會面臨中間人攻擊的風險。那客戶端是如何驗證這兩點的呢？

首先，在將服務器公鑰提供給 CA 時，CA 會使用自己的私鑰對服務器公鑰進行簽名。注意，這里是私鑰，不是公鑰。然后客戶端拿到這個證書之后，會使用 CA 的公鑰（內(nèi)置在瀏覽器中）對其進行解密，然后拿到 CA 側(cè)登記證書時計算的 Hash 值，然后客戶端會根據(jù)證書上的信息，使用同樣的算法計算出另一個 Hash 值，然后將這兩個 Hash 值對比，就能夠知道證書是否可信賴。當然，這個只是其中的一個步驟，CA 的認證還涉及到信任鏈的問題，這里不展開。

當然，CA 也不能解決全部的問題。之前也出過 CA 機構(gòu)被黑的事故，非法頒發(fā)了 Google 和 Twitter 的偽造證書。

HTTPS 握手過程

握手的過程，總結(jié)成了一張圖，其實就是將上面將的 HTTPS 的加密原理細化了一下：

標簽：

推薦

財富更多》

動態(tài)更多》

熱點