什麼是 TLS 中間人攻擊？如何防範這類攻擊？

12-29

（圖片來自：Deep Shit 9的廣播）
據說 github 受到來自某機構的 TLS mim 攻擊，請問什麼是 TLS mim 攻擊？有什麼危害？如何防範？如何確定是否被攻擊？

@Rio 的故事雖然生動，但是是有錯誤的。通過TLS加密通信，一旦會話初始化完成，想要完成中間人攻擊是非常困難的。TLS的中間人攻擊是針對加密會話的初始化階段進行的，而不是實際通信的階段。加密通信的初始化階段，需要通過非對稱密碼演算法來協商密鑰，然後用協商好的密鑰，使用對稱加密演算法進行實際的通信。

不知道各位有沒有見過一種鎖，當用鑰匙打開這種鎖之後，鑰匙就可以拔出來了，剩下一個開著的鎖頭。拿著這個開著的鎖，沒有鑰匙，一旦鎖上了就開不了。這是現實生活這的一種非對稱加密的物件，能上鎖，但是不能開鎖。

現在故事開始，假設我們回到了那個只能寄信的時代，大家都需要和知乎通信，而且通信的內容必須要保密。於是負責接收大家消息的@顧惜朝想出來一個辦法，找了很多把上面說的那種鎖（公鑰），都用鑰匙打開，掛在外面。需要和知乎通信的人，在通信之前，需要擁有另外一把有兩個鑰匙的鎖（對稱加密演算法），然後把這把鎖和其中一把鑰匙（對稱密鑰），放進一個無法被破拆的鐵盒子裡面，用知乎提供的那把開著的鎖把鐵盒子鎖上。

這時候，這個鐵盒子就無法打開了，除了擁有鑰匙的顧惜朝。這個裝有一把鎖和鑰匙的鐵盒子，可以放心地交到任何一個人手上，然後讓他拿去給顧惜朝。顧惜朝拿到這個鐵盒子之後，加密通信會話就建立了。她就會用鑰匙打開鐵盒子，取出鎖和鑰匙，寫下「親愛的知乎用戶，你好，我是顧惜朝」小紙條，放進鐵盒子里，然後用你提供的鎖把鐵盒子鎖上，然後交回到你的手上。這個時候，鐵盒子被你提供的鎖鎖上了，除了你和顧惜朝，沒有別人有鑰匙能夠打開這個鐵盒子，鐵盒子也就可以安全地經過郵遞送到你的手上；你收到鐵盒子之後，用你自己的鑰匙打開鎖，讀鐵盒子裡面的消息，然後放進新的小紙條，再寄送回去。

以上是加密通信的過程。

接下來，別有用心的@匿名用戶出現了，偷偷地換掉了幾個知乎打開放在外面的鎖，並且自己充當了郵遞員的身份在外面晃悠。當你需要和知乎通信的時候，匿名用戶遞給你一把他自己的鎖，騙你說這把是知乎掛在外面的鎖。當你把你自己的鎖和鑰匙放進去，然後交給匿名用戶，麻煩他把這些送給顧惜朝的時候，匿名用戶就可以找到另外一個鐵盒子，裝上自己的另外一把兩個鑰匙的鎖，用真正的知乎提供的鎖鎖上，然後寄給顧惜朝。我們辛勤的顧惜朝依然會正常的收到一個鐵盒子，裡面裝著一把鎖和一把鑰匙，只不過，這個鎖已經不是你的了，而是匿名用戶的，你的那把鎖實際上在匿名用戶手上。顧惜朝把「親愛的知乎用戶，你好，我是顧惜朝」的小紙條放進鐵盒，然後讓匿名用戶帶回去給你，而這個時候，匿名用戶就可以打開這個小鐵盒，偷看你們之間的消息，然後自己編造一條消息，放進鐵盒裡面，然後傳回去給你。

以上是中間人攻擊。

為了避免中間人攻擊，我們聰明的顧惜朝，發明了一種神奇的、無法撕毀、塗改和變造的小紙條（數字簽名），上面寫著「這把鎖經過顧惜朝認證，是知乎加密通信專用鎖」，然後在每一把知乎提供的鎖上貼上，這樣子匿名用戶就不能偽造鎖了，這時候這個鎖叫作證書。

但是問題又來了，許多新來的知乎用戶不認識顧惜朝，他們怎麼知道顧惜朝就是可信的，她認證的鎖就是可用的？於是@黃繼新在這個小紙條的下方又貼了一個小紙條，「顧惜朝經過黃繼新的認證，可以對知乎加密通信專用鎖進行認證」。黃繼新不僅可以認證鎖，還可以認證顧惜朝等管理員的權力，這時候黃繼新就是CA。可是問題還沒有解決，還是有很多知乎用戶不認識黃繼新，於是李開復又在黃繼新的小紙條上又貼了一個小紙條，「黃繼新經過李開復的認證，可以對知乎加密通信專用鎖進行認證」。問題依然沒有解決，還是有人不認識李開復，於是這時候需要一個權威的、人們無條件相信的機構來對李開復進行認證，這個機構就是根CA，他貼上去的小紙條就叫作根證書。

以上是信任體系，另見《既然這個世界沒有絕對的「權威」，那麼我們該相信誰？》。

最後一個問題，TLS的中間人攻擊怎麼實施。這時候@Rio出場了，因為是知乎的工作人員，具有一個可信的證書，類似於「Rio經過黃繼新的認證，可以對知乎加密通信專用鎖進行認證」。於是他自己偽造了一個鎖，然後利用上一級CA對他的信任，去騙取知乎用戶使用他提供的鎖初始化加密會話。因為他的鎖上面有上一級CA的認證，所以你會認為這個鎖是可信的，而實際上Rio通過自己擁有的證書，可以實施中間人攻擊，竊取你和顧惜朝之間通信的內容。

以上便是TLS的中間人攻擊。

手裡掌握權力的人，只有道德能夠防止他做壞事。

什麼是 TLS mim 攻擊？
安全套接層在這裡有說明
mim 就是man in the middle，中間人攻擊

正常情況下瀏覽器與伺服器在TLS鏈接下內容是加密的，第三方即使可以嗅探到所有的數據，也不能解密。
中間人可以與你建立鏈接，然後中間人再與伺服器建立鏈接，轉發你們之間的內容。這時候中間人就獲得了明文的信息。

有什麼危害？
你與伺服器的通信被第三方解密、查看、修改。

如何防範？如果確定是否被攻擊？
在訪問https鏈接的時候，查看一下伺服器提供的證書是不是正確的。
除非入侵併取得伺服器的證書私鑰，否則中間人是不能完全偽裝成伺服器的樣子的。
比如圖中的證書就是一個自簽名的證書，而github的證書不是自簽名的，而是 DigiCert High Assurance EV CA-1 這個簽名的。

證書是什麼？
TLS的握手依賴於「公開密鑰加密演算法（也叫非對稱演算法）」：加密密鑰（公鑰）和解密密鑰（私鑰）是不同的，從公鑰很難推出私鑰。
握手是為了雙方確定一個用作加密通信的密鑰（因為非對稱演算法很慢，所以只用來做密鑰交換）。
考慮一種簡單的模型：客戶端產生一串隨機數作為密鑰，使用伺服器發送過來的公鑰加密，再發送給伺服器。伺服器用對應的私鑰解密。
這種方式不能抵禦中間人攻擊，因為你不知道伺服器發來的公鑰是不是真的來自伺服器。這時候就需要一個可信的第三方來為伺服器作證。
證書就是伺服器的公鑰、伺服器的各種信息（比如「我是http://github.com", 我的這個公鑰最多能用到xxxx年x月x日），加上一個可信的第三方對公鑰和這些信息的簽名。
中間人無法偽造這個簽名，也就無法替換伺服器的公鑰。強行替換的話，只能找另外的機構簽名，或者自己給自己簽名。

另外：
自簽名很容易看出來，但是如果有不靠譜的CA（證書頒發機構）亂髮證書，而且正好這個CA在你的信任列表裡，就不太容易發現了。
這也是為什麼這麼多人呼籲刪除CNNIC ROOT CA。
Chrome有個新功能叫certificate pinning，也是為了處理中間人的這種情況。

說些題外話：
中間人攻擊在任何通信都會出現，但是防禦中間人攻擊的原則很簡單是：

必須對認證過程的傳輸者/認證過程的本身真實性進行認證。

只有這樣才能確認你的認證是完整的。

國內有些通信設備，因為加密能力不行，經常會假認證，空認證，不認證，降低設備的負載。

這時候通訊是正常的，但是其實也是MIM的一種了。

@Rio @余天升的故事雖然生動，但多少有些紕漏，稍微補充說明一下吧，可能會比較枯燥

先辨析加密演算法。為了讓數據中的信息不被外人識別，就需要用加密演算法處理。按照現代密碼學的思路，可以使用對稱密碼演算法或者非對稱密碼演算法進行處理。加密（使信息不可識別）和解密（將不可識別的數據處理成可識別的信息）過程中，使用相同密鑰的叫對稱密碼演算法，使用不同密鑰的叫非對稱密碼演算法。對稱密碼演算法很好理解，日常見到的所有的鎖，包括@余天升的例子，都是對稱密碼的實現。非對稱密碼演算法聽起來就有點神奇，而且不同演算法的基礎也大不一樣，常見的用法（如SSL/TLS中的實現）是：甲扔給乙一堆數據，然後乙用這些數據按照甲的指示處理要傳給甲的信息；之後，對於乙處理後的信息，只有甲能解讀，其他人就算知道了甲扔給乙的所有東西以及乙回傳給甲的全部信息，也沒法知道乙到底告訴了甲什麼內容。在甲和乙的通信過程中，甲告訴乙那堆數據主要就是「公鑰」，甲用來解讀乙回傳信息的數據就是「私鑰」。非對稱密碼演算法因此也叫公鑰密碼演算法。

對稱密碼演算法比非對稱密碼演算法對運算能力的要求低很多（根據早期的評估，同等破解強度同等運算能力的情況下，對稱密碼演算法比非對稱密碼演算法要快上千倍），而且非對稱密碼演算法面臨特定的安全攻擊時不夠強，所以在具體應用中，包括TLS，都是把兩種演算法混合使用：先用非對稱密碼演算法傳遞對稱密碼演算法所使用的密鑰，然後再用對稱密碼演算法處理實際需要傳遞的信息。這種混合使用兩種密碼演算法的系統就叫混和密鑰系統（hybrid cryptosystem）。

在實際的信息傳遞過程中，除了考慮演算法本身，一般來說重點還在於怎麼樣去部署。要實現信息的正確傳遞，首先要做的是確認對方的身份，如果根本就找錯了人，那肯定沒法保證安全：本來甲是要和乙通信，可如果他沒法認出是丙在冒充乙，那不管他用了多強的演算法都沒用。中間人（ MIM, man-in-the-middle）攻擊就是在甲和乙通信的過程中，丙冒充乙去和甲通信，同時冒充甲去和乙通信，從而實現對信息的截獲、監控、審查和進一步處理。

TLS協議的實現中，確認對方身份的基礎是對機構的信任，最主要的是確認被訪問的網站就是你要去的那個。網站(http://github.com)從具有公信力的機構（DigiCert）申請一張證書(certificate)，這樣用戶訪問github時就可以通過查看它的證書來驗明正身，這個網站就是github。而且，證書上有github的公鑰，用戶就用這個公鑰去與github用非對稱密碼演算法協商出傳輸網頁內容的對稱密碼演算法的密鑰。只要GFW不知道協商出來的對稱密碼演算法的密鑰，它就不知道用戶和github之間傳遞了什麼信息。

上面說到，網站的證書是有公信力的機構簽發的，但什麼樣的機構才「有公信力」呢？這就需要用戶自己（主要是瀏覽器的設置）判斷了。而且，從大機構申請和維護證書的有效性需要走流程和花錢，有些時候小網站或特殊場合就會用到自簽名證書，就是說網站自己根據標準格式生成了一張證書，讓那些信任它的用戶去使用。

就這樣，因為對加密演算法和國外有公信力的機構沒辦法，GFW就把主意打到證書上來了。所有對外的網路訪問都需要經過GFW，這樣當GFW發現有人要訪問github了，它就攔在中間，冒充github與牆內的用戶通信，冒充用戶去訪問github。在牆內用戶要確認github身份的時候，他就用自己生成的自簽名假證應付。

好在大家用的瀏覽器都有一個列表，用以確認哪些機構簽發和哪些網站自簽名的證書是可信的。由於 github不在認可的自簽名網站列表中，大家去訪問github時瀏覽器遇到自簽名的證書就會有告警，從而幫助我們識破了GFW的伎倆。

要防範TLS的中間人攻擊，首先是不信任不該信任的機構和網站。由於可信機構可以進一步授權下級機構，需要特別小心那些頂級證書機構，尤其需要注意的是CNNIC在很多時候已經在不少瀏覽器的默認信任列表中了。其次，要對瀏覽器的告警保持足夠的警惕，遇到提示要仔細確認無害後再繼續操作。當然，最好是那些做惡的傢伙都不復存在。。。

TLS和數字證書的信任體系建立在CA信任根的基礎之上。如果CA作惡，整個信任體系就將崩潰。嚴格來說，作為電子認證服務機構的CA是需要有工信部的資質的。實際情況是，你IE里安裝了根證書的CA，有很多都沒有牌照，即在監管之外。存在著作惡的可能性。