在HTTP里，一切都是明文傳輸?shù)?，流量在途中可隨心所欲的被控制。而在線使用的 WebApp，流量里既有通信數(shù)據(jù)，又有程序的界面和代碼，劫持簡(jiǎn)直輕而易舉。

HTTPS雖然不是絕對(duì)安全，但運(yùn)營(yíng)商要想劫持也不是這么簡(jiǎn)單的事情。

下面我們來(lái)聊一聊HTTPS如何做到防劫持。

SSL握手

先來(lái)看看HTTPS建立連接的過(guò)程，相比HTTP的三次握手，HTTPS在三次握手之后多了SSL握手。如下圖：

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

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

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

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

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

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

c) 使用約定好的HASH計(jì)算握手消息，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密。這個(gè)加密過(guò)程是非對(duì)稱加密，即公鑰加密，私鑰解密。私鑰只在網(wǎng)站服務(wù)器上存儲(chǔ)，其他人無(wú)法獲得這個(gè)私鑰，也就無(wú)法解密。可理解為公鑰是鎖，私鑰是鑰匙，客戶端將隨機(jī)數(shù)用公鑰鎖上，經(jīng)過(guò)網(wǎng)絡(luò)傳輸?shù)椒?wù)器，整個(gè)過(guò)程就算有人攔截了信息，由于沒(méi)有私鑰解鎖，也就無(wú)法解密。

過(guò)程如下圖：

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

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

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

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

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

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

如何防劫持

對(duì)于HTTP請(qǐng)求來(lái)說(shuō)，常見(jiàn)的劫持有DNS劫持和內(nèi)容劫持。

舉個(gè)網(wǎng)上的例子，有人在知乎問(wèn)過(guò)一個(gè)問(wèn)題。

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

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

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

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

如果他要假冒其他機(jī)構(gòu)頒發(fā)證書，因?yàn)闆](méi)有頒發(fā)機(jī)構(gòu)的秘鑰，那么這個(gè)證書的指紋一定沒(méi)辦法對(duì)上，還是一樣會(huì)報(bào)警。

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

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

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

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

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

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

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

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

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

Charles

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

電腦端配置根證書

移動(dòng)端的證書信任圖

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

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

參考文章
HTTPS知識(shí)點(diǎn)整理

我是咕咕雞，一個(gè)還在不停學(xué)習(xí)的全棧工程師。
熱愛(ài)生活，喜歡跑步，家庭是我不斷向前進(jìn)步的動(dòng)力。