關於Https安全性問題、雙向驗證防止中間人攻擊問題

版權聲明：本文爲博主原創文章，未經博主允許不得轉載；如需轉載，請保持原文鏈接。

HTTPS中間人攻擊及防禦

HTTPS也不是絕對安全的，在HTTPS握手的過程中，如果實施不當，還是會存在漏洞，很容被中間人攻擊；

什麼是中間人攻擊：

中間人攻擊（Man-in-the-middle attack，縮寫：MITM）是指攻擊者與通訊的兩端分別創建獨立的聯繫，並交換其所收到的數據，使通訊的兩端認爲他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容，達到HTTPS攻擊的目的。維基百科：

如何進行中間人攻擊的呢？

攻擊一：SSLSniff

攻擊者在網關截獲SSL會話，替換服務器公鑰證書，將公鑰PKey換成自己的公鑰PKey，欺騙客戶端。客戶端使用PKey加密信息併發送會話，中間人用私鑰Skey解密客戶端返回會話，從而劫持會話。同時，中間人用PKey加密明文會話並返回服務器

過程如下：

1. Attacker截獲了客戶端的say hello，可以把publicKey_attacker返回給客戶端，取得客戶端的信任，至此Attacker與客戶端建立了安全連接。
2. Attacker冒充客戶端向服務器發送say hello，至此Attacker與服務器建立了安全連接。

這種攻擊會存在一個問題會被感知到，就是Attacker的證書是僞造的不受信任的證書，所以客戶端可以確認是否需要真的連接該服務器，不過如果有內鬼的話，僞造的受信任的證書的話，就當我啥也沒說；

攻擊二：SSLStrip

這種攻擊相對於攻擊一複雜一點，但是也更加厲害，幾乎可以在客戶端無感知的情況下實施攻擊，並且不需要僞造證書；簡單來說就是這樣：Attacker在客戶端與服務器建立連接時，在Attacker與服務器之間形成HTTPS連接，而在客戶端與Attacker之間形成HTTP連接，即將SSL層從原HTTPS連接中“剝離”。這樣，既避免了在客戶端驗證證書時難以避免的彈框問題，又能夠劫持HTTP明文數據，並同時保證客戶端HTTP數據的傳輸，達到欺騙服務器與客戶端的效果。

過程如下：

用戶在瀏覽器地址欄中輸入網址時，多數會採用直接輸入網址的方式，而忽略了傳輸所採用的協議。例如，在登錄gmail過程中，大多數用戶會直接在地址欄中輸入www.gmail.com，向Google服務器發送一個HTTP連接請求，而不是輸入https：//www.gmail.com， 向服務器發送一個HTTPS連接請求。因此，用戶通常接觸到HTTPS的方式有兩種：一種是 Web上的連接，比如當用戶在gmail上輸入用戶名和密碼後，點擊的登錄鍵，將用戶的用戶名和密碼以HTTPS的形式POST到服務器。另一種是通過HTTP的302狀態。 當客戶端向gmail提出HTTP連接請求時，gmail服務器會返回一個REDIRECT網址，https：//www.google.com/accounts/ServiceLogin?service=mail...，用戶端在接收到這個URL後，將頁面重定位到該網頁，並請求HTTPS連接。 從另外一個角度講，用戶通常是通過HTTP向服務器發起HTTPS連接的。而HTTP本身是以明文的形式對外傳送，並不能保證數據的安全。因此，可以考慮通過對HTTP進行劫持，來實現對HTTPS劫持的目的。

1. 客戶端向服務器發起HTTP連接請求；
2. 中間人MITM監聽客戶端與服務器的HTTP數據；
3. 服務器返回給客戶端的HTTP數據包被在客戶端與服務器之間的中間人截獲。中間人解析原HTTP數據包，將其中<a href=”https：//...”>替換成<a href=”http//...”>，將 Location： https：//... 替換成Location：http://..，同時記錄下所修改的URL，並保存；
4. 中間人將修改後的HTTP數據發送給客戶端；
5. 客戶端向服務器發起HTTP連接請求；
6. 中間人計算機解析客戶端的HTTP連接請求，並與保存文件相比較。當發現存在有已修改過的HTTP URL時，將其替換成原HTTPS URL，併發送給服務器；
7. 與服務器保持HTTPS連接，回到步驟3；
8. 與客戶端保持HTTP連接，回到步驟4。

效果就是： 服務器認爲HTTPS是安全的。對於客戶端而言，由於中間人MITM與客戶端Client之間是HTTP連接，因此並不會對證書進行認證；

當然還有別的攻擊方式，這裏只着重介紹這兩種

如何防禦中間人攻擊？

中間人攻擊是一個（缺乏）相互認證的攻擊；由於客戶端與服務器之間在SSL握手的過程中缺乏相互認證而造成的漏洞

防禦中間人攻擊的方案通常基於一下幾種技術

1. 公鑰基礎建設PKI

使用PKI相互認證機制，客戶端驗證服務器，服務器驗證客戶端；上述兩個例子中都是隻驗證服務器，這樣就造成了SSL握手環節的漏洞，而如果使用相互認證的的話，基本可以

1. 更強力的相互認證

2. 延遲測試

使用複雜加密哈希函數進行計算以造成數十秒的延遲；如果雙方通常情況下都要花費20秒來計算，並且整個通訊花費了60秒計算纔到達對方，這就能表明存在第三方中間人。

1. 使用其他形式的密鑰交換形式

未完待續。。。https://blog.csdn.net/u010731949/article/details/50538280