在HTTP里,，一切都是明文傳輸?shù)模髁吭谕局锌呻S心所欲的被控制,。而在線使用的 WebApp,，流量里既有通信數(shù)據(jù)，又有程序的界面和代碼,，劫持簡直輕而易舉,。

HTTPS雖然不是絕對安全，但運營商要想劫持也不是這么簡單的事情,。

下面我們來聊一聊HTTPS如何做到防劫持,。

SSL握手

先來看看HTTPS建立連接的過程，相比HTTP的三次握手,，HTTPS在三次握手之后多了SSL握手,。如下圖：

整個流程大概如下：
1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。

2.網(wǎng)站部署了一組SSL秘鑰,，分私鑰和秘鑰,。

3.網(wǎng)站從瀏覽器的加密規(guī)則中選出一組加密算法與HASH算法，并將自己的身份信息（公鑰）以證書的形式發(fā)回給瀏覽器,。證書里面包含了網(wǎng)站地址,，加密公鑰，以及證書的頒發(fā)機構(gòu)等信息,。

4.獲得網(wǎng)站證書之后瀏覽器要做以下工作：

a) 驗證證書的合法性（頒發(fā)證書的機構(gòu)是否合法,，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任,，則瀏覽器欄里面會顯示一個小鎖頭,，否則會給出證書不受信的提示。

b) 如果證書受信任,，或者是用戶接受了不受信的證書,，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密。

c) 使用約定好的HASH計算握手消息,，并使用生成的隨機數(shù)對消息進行加密,。這個加密過程是非對稱加密，即公鑰加密,，私鑰解密,。私鑰只在網(wǎng)站服務(wù)器上存儲，其他人無法獲得這個私鑰,，也就無法解密?？衫斫鉃楣€是鎖,，私鑰是鑰匙，客戶端將隨機數(shù)用公鑰鎖上,，經(jīng)過網(wǎng)絡(luò)傳輸?shù)椒?wù)器,，整個過程就算有人攔截了信息，由于沒有私鑰解鎖,，也就無法解密,。

過程如下圖：

5.將生成的所有信息發(fā)送給網(wǎng)站。

6.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后,，使用自己的私鑰將信息解密取出密碼,，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致,。

7.使用密碼加密一段握手消息,，發(fā)送給瀏覽器。

8.瀏覽器解密并計算握手消息的HASH,，如果與服務(wù)端發(fā)來的HASH一致,，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密,。

這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證,，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù),，為后續(xù)真正數(shù)據(jù)的傳輸做一次測試,。

備注：非對稱加密算法用于在握手過程中加密生成的密碼，對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密,，而HASH算法用于驗證數(shù)據(jù)的完整性,。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關(guān)鍵，因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密,。非對稱加密算法會生成公鑰和私鑰,，公鑰只能用于加密數(shù)據(jù)，因此可以隨意傳輸，而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密,，所以網(wǎng)站都會非常小心的保管自己的私鑰,，防止泄漏。

如何防劫持

對于HTTP請求來說,，常見的劫持有DNS劫持和內(nèi)容劫持,。

舉個網(wǎng)上的例子，有人在知乎問過一個問題,。

在瀏覽器輸入如下域名https:// www.zhihu.com那瀏覽器要打開這個網(wǎng)站,，首先要解析域名www.zhihu.com,結(jié)果這個域名被黑客劫持到他的私人服務(wù)器1.2.3.4,結(jié)果我的瀏覽器和他 的私人服務(wù)器1.2.3.4建立SSL連接，他的服務(wù)器1.2.3.4也和www.zhihu.com建立SSL的連接,，我收發(fā)的數(shù)據(jù)都通過他的服務(wù)器1.2.3.4中轉(zhuǎn),，也就是黑客的服務(wù)器1.2.3.4相當(dāng)于一個https代理服務(wù)器，結(jié)果我收發(fā)的所有數(shù)據(jù),，他都能看到,。可能這樣被劫持嗎,？

這個黑客的攻擊就是通常說的中間人攻擊,，跳轉(zhuǎn)1.2.3.4就是DNS劫持，DNS被劫持到一個非源端的IP上,。我們根據(jù)上文SSL握手的流程來分析一下,，這種可能性是否存在。

首先如果黑客要跟你的瀏覽器建立SSL連接,，那么他需要有一個CA證書,，而通常系統(tǒng)內(nèi)置根證書都是大型機構(gòu)的根證書，幾乎無法偽造,。如果非要做一個只能是自簽名證書,。

瀏覽器拿著對方的自簽名證書和系統(tǒng)證書進行校驗，結(jié)果一定是如下圖所示：

如果他要假冒其他機構(gòu)頒發(fā)證書,，因為沒有頒發(fā)機構(gòu)的秘鑰,，那么這個證書的指紋一定沒辦法對上，還是一樣會報警,。

除非用戶自己主動導(dǎo)入一個自己信任的證書,。

記住，不要隨便安裝受信任證書,，否則HTTPS也幫不了你,。我們平時為了調(diào)試HTTPS請求，使用Charles/MitmProxy進行抓包,，也需要在手機端導(dǎo)入一個證書,，讓用戶選擇信任安裝,，目的就是將Charles/MitmProxy作為中間人代理，如果沒有用戶信任安裝證書的過程,，也同樣無法解析HTTPS的請求包,。

還有人就說了，我可以讓用戶回落到HTTP協(xié)議啊,，中間人用HTTPS跟服務(wù)器通信,，然后用HTTP跟客戶端通信——要知道大部分用戶在地址欄輸入URL時，并沒有指定協(xié)議的習(xí)慣,，都是打www開頭而不是打https://www開頭,，能用HTTPS全是Web+Server上80端口301+Location到HTTPS的功勞。

看起來似乎中間人充當(dāng)了一個替換頁面里HTTPS資源到HTTP的反向代理,，好像可行性還是很高,。

但是只要利用HSTS（HTTP+Strict+Transport+Security，RFC6797）就可以解決這個問題,。通過在HTTP+Header中加入Strict-Transport-Security的聲明,，告訴瀏覽器在一定時間內(nèi)必須通過HTTPS協(xié)議訪問本域名下的資源,。

這種情況下,，只要用戶曾經(jīng)在安全網(wǎng)絡(luò)環(huán)境下訪問過一次某站，中間人在指定時間內(nèi)也無法讓其回落到HTTP,。

解決完DNS劫持,，再看內(nèi)容劫持就簡單多了。

你作為一個中間人,，你沒有服務(wù)器私鑰A,，是不能解密客戶端發(fā)送的內(nèi)容的，如果你沒有客戶端自己生成的密鑰B,，所以你也不能解密客戶端發(fā)過去的內(nèi)容的,。

總結(jié)：
1.CA證書保證了公鑰的可靠性。
2.服務(wù)端私鑰+公鑰的非對稱加解密保證了客戶端生成的隨機數(shù)傳輸安全,，不會被中間人攔截獲取,。But，非對稱加密對服務(wù)端開銷大,。
3.所以利用隨機數(shù)的對稱加密保證后續(xù)通訊的安全性,，也可以降低服務(wù)器的解密開銷。
4.HTTPS只針對傳輸內(nèi)容進行加密,，保證的是客戶端和網(wǎng)站之間的信息就算被攔截也無法破解,。如果不是全站HTTPS，僅僅只是在登錄頁采用HTTPS,，那些HTTP連接的頁面同樣是危險的,，從HTTP->HTTPS跳轉(zhuǎn)依然可能被劫持,。國內(nèi)的部分銀行就是這樣，對安全性的考量還比不上百度,，百度早就全站HTTPS了,。

Charles

上文中提到利用Charles抓取HTTPS數(shù)據(jù)，看看下圖就知道了,。

電腦端配置根證書

移動端的證書信任圖

如果你對Charles的自簽名證書選擇不信任,，那么Charles也無法做到中間人解密。

整個過程：手機----》Charles ----》 服務(wù)器,， Charles 即充當(dāng)了服務(wù)端又充當(dāng)了客戶端,，才使得數(shù)據(jù)能夠正常的交互，在一次請求中數(shù)據(jù)被兩次加解密,，一次是手機到Charles,，一次是Charles到真正的服務(wù)端。這個過程中最重要的一環(huán)就是手機端安裝的根證書,！

參考文章
HTTPS知識點整理

我是咕咕雞,，一個還在不停學(xué)習(xí)的全棧工程師。
熱愛生活,，喜歡跑步,，家庭是我不斷向前進步的動力。