摘要：中間人攻擊及其防范在之前的文章中，筆者簡(jiǎn)要介紹了一下的工作原理，在擴(kuò)展閱讀中，筆者提到了中間人攻擊，簡(jiǎn)稱(chēng)而在本文中，筆者將進(jìn)一步解釋什么是中間人攻擊。而中間人攻擊不僅僅局限于針對(duì)，對(duì)于開(kāi)放性的連接，中間人攻擊非常容易。

在之前的文章中，筆者簡(jiǎn)要介紹了一下 HTTPS 的工作原理，在擴(kuò)展閱讀中，筆者提到了中間人攻擊（Man In The Middle Attack，簡(jiǎn)稱(chēng) MITM）而在本文中，筆者將進(jìn)一步解釋什么是中間人攻擊。

以下內(nèi)容來(lái)自維基百科中的中間人攻擊詞條：

在密碼學(xué)和計(jì)算機(jī)安全領(lǐng)域中，中間人攻擊（Man-in-the-middle attack，縮寫(xiě)：MITM）是指攻擊者與通訊的兩端分別建立獨(dú)立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認(rèn)為他們正在通過(guò)一個(gè)私密的連接與對(duì)方直接對(duì)話，但事實(shí)上整個(gè)會(huì)話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容。在許多情況下這是很簡(jiǎn)單的（例如，在一個(gè)未加密的Wi-Fi 無(wú)線接入點(diǎn)的接受范圍內(nèi)的中間人攻擊者，可以將自己作為一個(gè)中間人插入這個(gè)網(wǎng)絡(luò)）。

簡(jiǎn)單來(lái)說(shuō)攻擊者就是一個(gè)介入通信的傳話員，攻擊者知道通信雙方的所有通信內(nèi)容，而且可以任意增加、刪除、修改雙方的通信內(nèi)容，而雙方對(duì)此并不知情。

而中間人攻擊不僅僅局限于針對(duì) HTTPS，對(duì)于開(kāi)放性的連接，中間人攻擊非常容易。比如在一個(gè)未加密的 Wi-Fi 網(wǎng)絡(luò)中，一個(gè)攻擊者可以很容易地將自己插入雙方的通信之中以截取或者修改通信的內(nèi)容。

假設(shè) Tom 想和 Jerry 交換一些秘密信息，然而 Tom 又不想跑到 Jerry 家里，于是 Tom 叫來(lái)了郵遞員，給了郵遞員一封信。信的內(nèi)容是希望 Jerry 給 Tom 一個(gè)盒子（這個(gè)盒子有兩把鑰匙）和其中一把鑰匙（另一把在 Jerry 手里）。

郵遞員在拿到 Tom 給的信件以后，把 Tom 的信拆開(kāi)看了一遍，了解到 Tom 希望 Jerry 給 Tom 一個(gè)有鎖的盒子，又用另一個(gè)信封裝了回去，并交給了 Jerry。

Jerry 在收到 Tom 的信（實(shí)際已經(jīng)被郵遞員拆閱過(guò)了）之后，給了郵遞員一個(gè)有鎖的盒子和其中一把鑰匙。

郵遞員想知道他們的通信內(nèi)容，于是他把 Jerry 給 Tom 的盒子換成了他自己的盒子，并附上了自己盒子中的一把鑰匙，并在之后將自己的盒子交給了 Tom。

Tom 在收到盒子之后，以為這個(gè)盒子是 Jerry 給他的，于是就把秘密的信件放進(jìn)了盒子里，并把鑰匙留下了，之后又交給了郵遞員。

郵遞員在拿到盒子之后，用自己的另一把鑰匙打開(kāi)盒子，看了里面的信件。之后將信件調(diào)換之后放進(jìn)了 Jerry 給的盒子，交給了 Jerry。

Jerry 在拿到郵遞員給他的盒子之后，并不知道這個(gè)盒子里的信件其實(shí)已經(jīng)被郵遞員調(diào)換過(guò)了，所以 Jerry 認(rèn)為盒子里的信件是來(lái)自 Tom 且未被修改過(guò)的。之后 Jerry 把回信放進(jìn)了盒子里，又交給了郵遞員。

郵遞員再次調(diào)換盒子里的信件，交給了 Tom。

這就是一個(gè)典型中間人攻擊的過(guò)程。在 HTTPS 中，Tom 就是客戶(hù)端，Jerry 是服務(wù)端，而郵遞員就是客戶(hù)端和服務(wù)端之間的任何實(shí)體（包括代理服務(wù)器、路由器、反向代理服務(wù)器等等），兩把鑰匙分別是公鑰和私鑰。通信雙方并不知道（且通常很難發(fā)覺(jué)）自己其實(shí)在和中間人通信而非直接和對(duì)方通信。在通信過(guò)程中，Tom 和 Jerry 并沒(méi)有驗(yàn)證對(duì)方的身份，這就導(dǎo)致了郵遞員可以任意查看、修改或者丟棄雙方的通信內(nèi)容。

從上面的例子看起來(lái)，似乎任何在通信雙方的實(shí)體都可以實(shí)施中間人攻擊，那么 HTTPS 是如何防止中間人攻擊的呢？要防止被中間人攻擊，那么就要確保通信中的信息來(lái)自他聲稱(chēng)的那個(gè)人，且沒(méi)有被修改過(guò)。在現(xiàn)實(shí)中，有多種方式可以確定某個(gè)實(shí)體的身份，比如個(gè)人的簽名 / 私章、組織的公章、甚至古時(shí)的信物。大部分情況下，只需要在信件最后蓋上簽上自己的名字或者蓋上組織的公章，那么接收者就可以確定這封信件就來(lái)自于他所聲稱(chēng)的那個(gè)人 / 組織。在二進(jìn)制的世界中，可以使用數(shù)字簽名來(lái)確保某段消息 / 某份文件確實(shí)是由他所聲稱(chēng)的那個(gè)實(shí)體所發(fā)出來(lái)的。

在之前的文章中，我們介紹過(guò)非對(duì)稱(chēng)加密，其中公鑰是公開(kāi)的，而私鑰只有擁有者知道。用私鑰對(duì)某個(gè)文件 / 某段消息的散列值進(jìn)行簽名就像一個(gè)人親手在信件最后簽上了自己的名字一樣，證明這份文件 / 這段消息確實(shí)來(lái)自私鑰的擁有者（因?yàn)楣€是公開(kāi)的，私鑰只有擁有者知道，所以如果能用其公開(kāi)的公鑰解開(kāi)數(shù)字簽名，那就證明這條消息確實(shí)來(lái)自于他私鑰的擁有者），這就可以確保消息是來(lái)自他所聲稱(chēng)的那個(gè)實(shí)體。這樣，在通信中，雙方每次在寫(xiě)完消息之后，計(jì)算消息的散列值，并用自己的私鑰加密生成數(shù)字簽名，附在信件后面，接收者在收到消息和數(shù)字簽名之后，先計(jì)算散列值，再使用對(duì)方的公鑰解密數(shù)字簽名中的散列值，進(jìn)行對(duì)比，如果一致，就可以確保該消息確實(shí)是來(lái)自于對(duì)方，并且沒(méi)有被篡改過(guò)。

不過(guò)有個(gè)問(wèn)題，如果中間人在會(huì)話建立階段把雙方交換的真實(shí)公鑰替換成自己的公鑰了，那么中間人還是可以篡改消息的內(nèi)容而雙方并不知情。為了解決這個(gè)問(wèn)題，需要找一個(gè)通信雙方都信任的第三方來(lái)為雙方確認(rèn)身份。這就像大家都相信公證處，公證處拿著自己的公章為每一封信件都蓋上了自己的章，證明這封信確實(shí)是由本人發(fā)出的，這樣就算中間人可以替換掉通信雙方消息的簽名，也無(wú)法替換掉公證處的公章。這個(gè)公章，在二進(jìn)制的世界里，就是數(shù)字證書(shū)，公證處就是 CA（數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)）。

數(shù)字證書(shū)就是申請(qǐng)人將一些必要信息（包括公鑰、姓名、電子郵件、有效期）等提供給 CA，CA 在通過(guò)各種手段確認(rèn)申請(qǐng)人確實(shí)是他所聲稱(chēng)的人之后，用自己的私鑰對(duì)申請(qǐng)人所提供信息計(jì)算散列值進(jìn)行加密，形成數(shù)字簽名，附在證書(shū)最后，再將數(shù)字證書(shū)頒發(fā)給申請(qǐng)人，申請(qǐng)人就可以使用 CA 的證書(shū)向別人證明他自己的身份了。對(duì)方收到數(shù)字證書(shū)之后，只需要用 CA 的公鑰解密證書(shū)最后的簽名得到加密之前的散列值，再計(jì)算數(shù)字證書(shū)中信息的散列值，將兩者進(jìn)行對(duì)比，只要散列值一致，就證明這張數(shù)字證書(shū)是有效且未被篡改過(guò)的。

通信過(guò)程的安全性自下而上就是這樣保證的：

雙方通信內(nèi)容的安全性是靠公鑰加密、私鑰解密來(lái)保證的，這一安全性由非對(duì)稱(chēng)加密的特性，即由公鑰加密的信息只能使用對(duì)應(yīng)的私鑰才能解開(kāi)來(lái)保證。由于私鑰不會(huì)傳遞，只有擁有者知道，所以安全性就由公鑰的正確性來(lái)保證。

公鑰由對(duì)方在通信初始所提供，但是這時(shí)很容易被中間人替換掉，為了保證公鑰的正確性，所以在發(fā)送公鑰的時(shí)候也會(huì)提供對(duì)應(yīng)的數(shù)字證書(shū)，用于驗(yàn)證這個(gè)公鑰是對(duì)方的而不是中間人的。那么安全性就是由數(shù)字證書(shū)的正確性來(lái)保證了。

數(shù)字證書(shū)是由上級(jí) CA 簽發(fā)給個(gè)人 / 組織的，上級(jí) CA 用自己的私鑰給個(gè)人證書(shū)進(jìn)行簽名，保證證書(shū)中的公鑰不被篡改，而接受者需要用上級(jí) CA 證書(shū)中的公鑰來(lái)解密個(gè)人數(shù)字證書(shū)中的數(shù)字簽名來(lái)驗(yàn)證證書(shū)中的公鑰是否是正確的。那么安全性就是由上級(jí) CA 證書(shū)的正確性保證的了。

但是，上級(jí) CA 證書(shū)也是由其上級(jí) CA 簽發(fā)的，這種信任關(guān)系一直到根證書(shū)。根證書(shū)沒(méi)有上級(jí) CA 為其簽名，而是自簽名的，也就是說(shuō)，它自身為自身簽名，保證正確性。所以根證書(shū)就是這個(gè)信任鏈最重要的部分。如果根證書(shū)泄露的話，其簽名的所有證書(shū)及使用其簽名的證書(shū)所簽名的證書(shū)的安全性將不復(fù)存在?，F(xiàn)在，安全性就是靠系統(tǒng)根證書(shū)的私鑰不被泄露或者其公鑰不被篡改來(lái)保證的了。

根證書(shū)不應(yīng)該通過(guò)網(wǎng)絡(luò)分發(fā)，因?yàn)橥ㄟ^(guò)網(wǎng)絡(luò)分發(fā)的話，可能會(huì)被中間人攻擊。一般根證書(shū)都通過(guò)操作系統(tǒng)或者瀏覽器分發(fā)，在操作系統(tǒng)中會(huì)內(nèi)置很多根證書(shū)，但是最初的操作系統(tǒng)也不能通過(guò)網(wǎng)絡(luò)分發(fā)，因?yàn)橹虚g人可以修改操作系統(tǒng)中的根證書(shū)。所以要保證安全只能靠最原始的方法，當(dāng)面交流。硬件廠商會(huì)和證書(shū)簽發(fā)機(jī)構(gòu)合作，在電腦、手機(jī)等設(shè)備出廠的時(shí)候在其操作系統(tǒng)中內(nèi)置簽發(fā)機(jī)構(gòu)的根證書(shū)，再將這些設(shè)備分發(fā)出去，這樣，這些設(shè)備的用戶(hù)就可以安全地進(jìn)行信息交換了。所以，安全性就依賴(lài)于這些設(shè)備在分發(fā)到消費(fèi)者手中之前不會(huì)被惡意修改來(lái)保證了。

至此，整個(gè)信任鏈就建立起來(lái)了，只需要有一臺(tái)設(shè)備上安裝了可以信任的根證書(shū)，就可以用來(lái)分發(fā)更多安全的操作系統(tǒng)了。之后的所有信任鏈都是安全的了。

（題外話）這些設(shè)備在到消費(fèi)者手里之前有沒(méi)有被惡意修改，誰(shuí)都不知道。密碼學(xué)家想法設(shè)法想用程序而非人類(lèi)（因?yàn)槿祟?lèi)容易收到外界影響，是無(wú)法完全信任的）來(lái)保證安全，到最后還是離不開(kāi)人類(lèi)，而人類(lèi)恰恰是這些精妙設(shè)計(jì)中最容易出現(xiàn)問(wèn)題的一環(huán)。

HTTP 協(xié)議最初的時(shí)候是明文的，因?yàn)榘踩珕?wèn)題所以現(xiàn)在很多網(wǎng)站都在逐漸過(guò)渡到 HTTPS，然而對(duì)于大部分使用者來(lái)說(shuō)，他們并不知道 HTTP 和 HTTPS 之間的區(qū)別，在瀏覽器輸入地址的時(shí)候都是直接輸入 www.example.com 而非 https://www.example.com，在大部分情況下，如果一個(gè)網(wǎng)站啟用了 HTTPS，服務(wù)器會(huì)將這個(gè)請(qǐng)求使用 301 或者 302 狀態(tài)碼以及一個(gè) Location 頭部將請(qǐng)求從 80 端口重定向至使用 HTTPS 的 443 端口。但是，如果中間人劫持了使用者的網(wǎng)絡(luò)請(qǐng)求，那么中間人可以阻止客戶(hù)端與服務(wù)器建立 HTTPS 連接，而是一直使用不安全的 HTTP 連接，而中間人則和服務(wù)器建立正常的 HTTPS 連接，讓客戶(hù)端以為自己正在和真實(shí)服務(wù)器通信。這種攻擊手法稱(chēng)作 SSLTrip。

為了解決這個(gè)問(wèn)題，IETF（互聯(lián)網(wǎng)工程任務(wù)小組）引入了一個(gè)策略，叫做 HSTS (HTTP Strict Transport Security, HTTP 嚴(yán)格傳輸安全)。HSTS 的作用是強(qiáng)制客戶(hù)端與服務(wù)端建立安全的 HTTPS 連接，而非不安全的 HTTP 連接。如果一個(gè)站點(diǎn)啟用了 HSTS 策略，那么客戶(hù)端在第一次與該站點(diǎn)建立連接之后，在未來(lái)的一段時(shí)間內(nèi)（由一個(gè) HTTP 頭部控制，這個(gè)頭部為：Strict-Transport-Security），客戶(hù)端與該站點(diǎn)的所有連接都會(huì)直接使用 HTTPS，即使客戶(hù)端訪問(wèn)的是 HTTP，也會(huì)直接在客戶(hù)端重定向到 HTTPS 連接。

假設(shè) https://example.com 的響應(yīng)頭部含有 Strict-Transport-Security: max-age=31536000; includeSubDomains，這意味著：

在未來(lái)的 1 年時(shí)間里（即 31536000 秒中），只要瀏覽器向 example.com 或者其子域名發(fā)送請(qǐng)求，必須采用 HTTPS 來(lái)發(fā)起連接。即使用戶(hù)在地址欄里寫(xiě)的是 http://example.com，那也直接重寫(xiě)為 https://example.com 并直接發(fā)起 HTTPS 連接。

在接下去的一年中，如果服務(wù)器提供的 HTTPS 證書(shū)無(wú)效（不論是域名對(duì)不上還是自簽名還是不在有效期內(nèi)），用戶(hù)都無(wú)法訪問(wèn)該站點(diǎn)。

如果站點(diǎn)沒(méi)有啟用 HSTS，用戶(hù)可以忽略證書(shū)無(wú)效的警告，繼續(xù)建立連接，而如果站點(diǎn)啟用了 HSTS，那么用戶(hù)即使想冒風(fēng)險(xiǎn)，瀏覽器也不會(huì)繼續(xù)訪問(wèn)。

HSTS 可以很大程度上防止 SSLTrip 攻擊，不過(guò)這樣還是有個(gè)問(wèn)題，那就是要啟用 HSTS，瀏覽器至少要和服務(wù)器建立一次 HTTPS 連接，如果中間人一直阻止瀏覽器與服務(wù)器建立 HTTPS 連接，那么 HSTS 就失效了。解決這個(gè)問(wèn)題有個(gè)辦法，那就是將 HSTS 站點(diǎn)列表內(nèi)置到瀏覽器中，這樣只要瀏覽器離線判斷該站點(diǎn)啟用了 HSTS，就會(huì)跳過(guò)原先的 HTTP 重定向，直接發(fā)起 HTTPS 請(qǐng)求。