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

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

以下內容來自維基百科中的中間人攻擊詞條：

在密碼學和計算機安全領域中，中間人攻擊（Man-in-the-middle attack，縮寫：MITM）是指攻擊者與通訊的兩端分別建立獨立的聯系，并交換其所收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內容。在許多情況下這是很簡單的（例如，在一個未加密的Wi-Fi 無線接入點的接受范圍內的中間人攻擊者，可以將自己作為一個中間人插入這個網絡）。

簡單來說攻擊者就是一個介入通信的傳話員，攻擊者知道通信雙方的所有通信內容，而且可以任意增加、刪除、修改雙方的通信內容，而雙方對此并不知情。

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

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

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

Jerry 在收到 Tom 的信（實際已經被郵遞員拆閱過了）之后，給了郵遞員一個有鎖的盒子和其中一把鑰匙。

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

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

郵遞員在拿到盒子之后，用自己的另一把鑰匙打開盒子，看了里面的信件。之后將信件調換之后放進了 Jerry 給的盒子，交給了 Jerry。

Jerry 在拿到郵遞員給他的盒子之后，并不知道這個盒子里的信件其實已經被郵遞員調換過了，所以 Jerry 認為盒子里的信件是來自 Tom 且未被修改過的。之后 Jerry 把回信放進了盒子里，又交給了郵遞員。

郵遞員再次調換盒子里的信件，交給了 Tom。

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

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

在之前的文章中，我們介紹過非對稱加密，其中公鑰是公開的，而私鑰只有擁有者知道。用私鑰對某個文件 / 某段消息的散列值進行簽名就像一個人親手在信件最后簽上了自己的名字一樣，證明這份文件 / 這段消息確實來自私鑰的擁有者（因為公鑰是公開的，私鑰只有擁有者知道，所以如果能用其公開的公鑰解開數字簽名，那就證明這條消息確實來自于他私鑰的擁有者），這就可以確保消息是來自他所聲稱的那個實體。這樣，在通信中，雙方每次在寫完消息之后，計算消息的散列值，并用自己的私鑰加密生成數字簽名，附在信件后面，接收者在收到消息和數字簽名之后，先計算散列值，再使用對方的公鑰解密數字簽名中的散列值，進行對比，如果一致，就可以確保該消息確實是來自于對方，并且沒有被篡改過。

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

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

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

雙方通信內容的安全性是靠公鑰加密、私鑰解密來保證的，這一安全性由非對稱加密的特性，即由公鑰加密的信息只能使用對應的私鑰才能解開來保證。由于私鑰不會傳遞，只有擁有者知道，所以安全性就由公鑰的正確性來保證。

公鑰由對方在通信初始所提供，但是這時很容易被中間人替換掉，為了保證公鑰的正確性，所以在發送公鑰的時候也會提供對應的數字證書，用于驗證這個公鑰是對方的而不是中間人的。那么安全性就是由數字證書的正確性來保證了。

數字證書是由上級 CA 簽發給個人 / 組織的，上級 CA 用自己的私鑰給個人證書進行簽名，保證證書中的公鑰不被篡改，而接受者需要用上級 CA 證書中的公鑰來解密個人數字證書中的數字簽名來驗證證書中的公鑰是否是正確的。那么安全性就是由上級 CA 證書的正確性保證的了。

但是，上級 CA 證書也是由其上級 CA 簽發的，這種信任關系一直到根證書。根證書沒有上級 CA 為其簽名，而是自簽名的，也就是說，它自身為自身簽名，保證正確性。所以根證書就是這個信任鏈最重要的部分。如果根證書泄露的話，其簽名的所有證書及使用其簽名的證書所簽名的證書的安全性將不復存在。現在，安全性就是靠系統根證書的私鑰不被泄露或者其公鑰不被篡改來保證的了。

根證書不應該通過網絡分發，因為通過網絡分發的話，可能會被中間人攻擊。一般根證書都通過操作系統或者瀏覽器分發，在操作系統中會內置很多根證書，但是最初的操作系統也不能通過網絡分發，因為中間人可以修改操作系統中的根證書。所以要保證安全只能靠最原始的方法，當面交流。硬件廠商會和證書簽發機構合作，在電腦、手機等設備出廠的時候在其操作系統中內置簽發機構的根證書，再將這些設備分發出去，這樣，這些設備的用戶就可以安全地進行信息交換了。所以，安全性就依賴于這些設備在分發到消費者手中之前不會被惡意修改來保證了。

至此，整個信任鏈就建立起來了，只需要有一臺設備上安裝了可以信任的根證書，就可以用來分發更多安全的操作系統了。之后的所有信任鏈都是安全的了。

（題外話）這些設備在到消費者手里之前有沒有被惡意修改，誰都不知道。密碼學家想法設法想用程序而非人類（因為人類容易收到外界影響，是無法完全信任的）來保證安全，到最后還是離不開人類，而人類恰恰是這些精妙設計中最容易出現問題的一環。

HTTP 協議最初的時候是明文的，因為安全問題所以現在很多網站都在逐漸過渡到 HTTPS，然而對于大部分使用者來說，他們并不知道 HTTP 和 HTTPS 之間的區別，在瀏覽器輸入地址的時候都是直接輸入 www.example.com 而非 https://www.example.com，在大部分情況下，如果一個網站啟用了 HTTPS，服務器會將這個請求使用 301 或者 302 狀態碼以及一個 Location 頭部將請求從 80 端口重定向至使用 HTTPS 的 443 端口。但是，如果中間人劫持了使用者的網絡請求，那么中間人可以阻止客戶端與服務器建立 HTTPS 連接，而是一直使用不安全的 HTTP 連接，而中間人則和服務器建立正常的 HTTPS 連接，讓客戶端以為自己正在和真實服務器通信。這種攻擊手法稱作 SSLTrip。

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

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

在未來的 1 年時間里（即 31536000 秒中），只要瀏覽器向 example.com 或者其子域名發送請求，必須采用 HTTPS 來發起連接。即使用戶在地址欄里寫的是 http://example.com，那也直接重寫為 https://example.com 并直接發起 HTTPS 連接。

在接下去的一年中，如果服務器提供的 HTTPS 證書無效（不論是域名對不上還是自簽名還是不在有效期內），用戶都無法訪問該站點。

如果站點沒有啟用 HSTS，用戶可以忽略證書無效的警告，繼續建立連接，而如果站點啟用了 HSTS，那么用戶即使想冒風險，瀏覽器也不會繼續訪問。

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