前言
很早以前看過HTTPS的介紹，並瞭解過TLS的相關細節，也相信使用HTTPS是相對安全可靠的。直到前段時間在驗證https代理通道連線時，搭建了MITM環境，才發現事實並不是我想的那樣。由於部分應用開發者忽視證書的校驗，或者對非法證書處理不當，讓我們的網路會話幾乎暴露在攻擊者面前。
下文會向大家展示的對IOS系統上2款常見的應用（知乎，360瀏覽器）進行中間人攻擊（Man-in-the-MiddleAttack，簡稱“MITM攻擊”）攻擊，獲取或篡改使用者資料。
基本介紹
中間人攻擊（Man-in-the-MiddleAttack，簡稱“MITM攻擊”）是指攻擊者與通訊的兩端分別建立獨立的聯絡，並交換其所收到的資料，使通訊的兩端認為他們正在通過一個私密的連線與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。中間人攻擊是一個（缺乏）相互認證的攻擊。大多數的加密協議都專門加入了一些特殊的認證方法以阻止中間人攻擊。例如，SSL協議可以驗證參與通訊的一方或雙方使用的證書是否是由權威的受信任的數字證書認證機構頒發，並且能執行雙向身份認證。
網上對中間人攻擊的介紹還算多，不過具體到實踐的就相對要少很多（這裡是指標對https的中間人攻擊實踐）
上圖簡單的表述了中間人攻擊的主要過程（上部為正常https流量，下部為被劫持的https流量），後面我們可以對著這個圖來實施我們自己的中間人攻擊。
準備中間人攻擊
需要提前準備些簡單常見工具：
1：Fiddler （注意雖然Fiddler抓取HTTPS報文的實際原理就是MITM，不過這裡當然不是用Fiddler實施中間人攻擊。因為Fiddler是自動完成的，也沒有實踐的意義，並且Fiddler需要被攻擊者自己提前匯入並信任根證書）
2：一個已經申請SSL證書的域名 （需要域名也意味著還需要一臺代理該域名的nginx伺服器，這裡之所以選擇一個真實的域名主要是為儘可能了還原現實的場景，如果您沒有域名也可以用ip代替，不過證書還是要提前準備好）
這裡用的是一個合法簽發的DV證書（網上其實可以很容易找到免費的證書），一般瀏覽器或客戶端校驗證書時，都會先檢查證書是否是“受信任的根證書頒發機構”頒發，再檢查SSL證書中的證書吊銷列表，再檢查檢查此SSL證書是否過期，再檢查SSL證書的網站的域名是否與當前訪問域名一致。如果使用一個合法簽發的證書實際上可以通過大部分校驗。
HTTPS 會話的發起是需要先建立SSL通道的。
我們藉助Fiddler將所有HTTPS的流量引導到我們自己的伺服器【lulianqi.com】
引導流量需要使用到FreeHttp外掛（https://www.cnblogs.com/lulia...可以在這裡下載該外掛），外掛安裝好後直接按下面截圖配置即可（FreeHttp本身具備強大的自定義報文篡改能力，如果有興趣可以在前面連結處檢視詳細內容）。
如上圖開啟Fiddler進入FreeHttp外掛頁籤，新增一個請求修改規則，點選確定，將規則新增到規則列表並勾選該規則，將其置為可用。（如果您沒有域名也可以用ip來代替，將http://lulianqi.com:443換成http://您伺服器的ip:443即可）（注意圖中紅色線框標記的地方，如以上設定啟用規則）
這裡簡單說明下使用代理的HTTPS請求會利用Connect請求建立SSL通道，我們修改Connect連線目標即可（因為這個時候SSL通道還沒有建立，目標地址還是明文，我們可以直接修改，這樣操作可以模擬網路中存在的攻擊）
FreeHttp預設跳過connect tunnels，所以這裡我們需要在設定項裡設定is skip connect tunnels 為否（按圖中提示操作即可）
然後是Fiddler自己的設定
如上圖，在Options中配置僅捕獲Connects，上面也有提到實際上我們不需要Fiddler進行中間人攻擊，所以不用解密，也不用在客戶端匯入證書
最後我們需要配置我們的伺服器【lulianqi.com】上的nginx （當然，在這之前您的nginx需要在伺服器上先安裝並配置好網路）
如上圖我們直接在nginx中新增一個server用於劫持會話（我們自己的域名要解析過來），證書使用的是lulianqi.com的一個dv證書。
這個nginx實際是就是中間人了，現在我們的中間人僅僅劫持流量（即被動網路攻擊），但一旦流量到了我們的伺服器而且SSL通道是與我們的伺服器建立的，即表示我們可以任意的處理這些流量，隨時都可以進行主動網路攻擊。
實施中間人攻擊
所有準備工作做完了我們就可以看下中間人攻擊的效果了
TLS對中間人攻擊的抵禦
當然正常情況下，我們的網路安全肯定不會這麼脆弱，所以暫時我們在下面看到的是在一切正常的情況下，看瀏覽器是如何藉助HTTPS（LTS）抵禦中間人攻擊的
用瀏覽器訪問https://www.baidu.com
得利於TLS證書體系，雖然我們能發起中間人攻擊，不過瀏覽器察覺到了證書的異常（這個時候就怕你點繼續瀏覽）
瀏覽器如何知道當前通道存在風險的，瀏覽器一開始就知道自己需要連線的主機是www.baidu.com，我們雖然通過網路劫持的方式讓瀏覽器以為我們的中間人伺服器就是www.baidu.com，不過我們的中間人伺服器卻沒有www.baidu.com的證書，所以我們依然使用了lulianqi.com的證書，前面我們也提到過了瀏覽器等客戶端會檢查“受信任的根證書頒發機構”，證書吊銷列表，SSL證書是否過期，證書籤發的域名。最後瀏覽器發現我們證書籤發的域名不是www.baidu.com，自然就知道了當前網路的風險，然後停止傳送真實業務請求，並向使用者提示或詢問。
（證書的校驗有賴於CA，而CA一般都是比較權威的組織機構，我們選擇信任他們)
如果使用者執意訪問，就會出現如上圖證書提示的錯誤，但同樣意味著您可能正處於攻擊下（事實上的確如此）
然後我們我伺服器就完美的劫持了使用者的會話，所有資訊都暴露了（所以遇到這樣的提示還是不要點確認比較好）
補充說明下上圖及下文中類似的圖片都是中間人伺服器nginx的訪問日誌，如果日誌中出現相應請求報文，即表示中間人攻擊實施成功。
這裡順便看下Chrome的表現
Chrome明顯對HSTS處理更為出色。因為對於已經開啟嚴格安全傳輸HSTS的www.baidu.com，瀏覽器發現證書錯誤後，Chrome的做法是直接禁止訪問，而Edge依然可以通過詢問的方式繼續訪問
上面的例項演示了中間人攻擊發起的基本過程，及瀏覽器是如何通過證書體系來抵禦中間人攻擊的。（HTTPS對中間人攻擊的抵禦）
還有一點需要說明上文及下文提到的流量或對話都是指HTTPS，如果您使用的是http那麼風險隨時都在。
無法抵禦中間人攻擊的例項（知乎，360瀏覽器）
現實中我們被手機陪伴的時間明顯更多，我們下面來看下手機上移動應用是否能抵禦這種中間人攻擊。
許多應用使用HTTPS與後端進行通訊，這種做法在系統程式，網站及移動應用中非常常見。不幸的是，應用開發者往往沒有正確的對證書進行校驗，這樣系統實際對攻擊者敞開了懷抱。
QA流程應該包括證書校驗方面的測試。
首先我們將手機連上Fiddler代理（注意這裡我們不需要讓手機安裝或信任任何第三方證書）
我們嘗試著如日常生活一樣使用手機（注意這裡測試使用的都是IOS上APP）
大部分應用出現了無法訪問，彈出式安全提示等反應
不過不幸的是仍然有一些應用無視了證書的保護，直接與危險的中間人伺服器建立了連線，並向使用者正常的顯示了頁面等資料。
下面列幾個代表性強的APP進行說明 （這裡不是特意選擇這些APP，只是我手機中正好安裝有，而且個人認為這些APP大家也比較常用）
1：知乎 （IOS版 4.34.1（1228） ）#
可以清楚看到知乎是完全無視了證書不匹配的錯誤，與沒有受到MITM時表現是一樣的，正常訪問，正常提交資料。但事實卻是所有流量都是通過中間人伺服器轉發到知乎的，中間伺服器解密了所有流量，並且可以對其進行篡改。更糟的是這一切發生的時候，使用者是完全不知情的。簡單的說就是當您在使用知乎APP瀏覽或發帖時，網路節點中的任何別有用心的人都是可以獲取您在瀏覽的內容，並對其進行修改。（這樣的描述一點都不誇張，後面會說明實際MITM中，也不會需要您的手機提前連線Fiddler代理，有許多可行且更隱祕的方式可以將流量引入中間人伺服器。如果應用不能識別到分享，就會跟上面描述的情況一樣）
2：360瀏覽器（IOS版本360瀏覽器 4.0.10）
其實某款特定APP由於自身安全問題不能抵禦MITM，最多也只會影響到自己的APP及自己的使用者，不過瀏覽器如果出現這種問題就會對使用者所有瀏覽的網站都有影響
特別是以安全為一大賣點的360，其自家瀏覽器的安全策略讓人無法理解
上面的截圖來自使用360瀏覽器分別瀏覽baidu及apple的情況，可以看到使用360手機瀏覽器瀏覽網頁（開啟https的網站），在受到MITM時只有一個不起眼的變化，那個原本應該是綠色的小盾牌變成了灰色，並且沒有向使用者進行任何詢問，直接就建立了不安全的SSL通道，後面的情況就很驚悚了，所有使用360手機瀏覽器瀏覽的內容全部被中間人伺服器劫持。
一開始自己也並不相信360手機瀏覽器會直接無視證書錯誤，不向使用者詢問。特意找了另一臺沒有安裝過360手機瀏覽器的手機（iphone6），在AppStore裡下載了新版本的360手機瀏覽器測試，結果是一樣的，除了那個不起眼的灰色小盾牌完全無視了證書域名不匹配的錯誤。（順便提一下上面的知乎也一樣，都用新手機測試過，的確有安全問題）
3：其他APP
當然我在自己手機了不只發現上面2款APP存在上面的問題，還有許多APP存在類似的問題，包括個別金融類應用，還有部分APP部分模組的流量存在被劫持的風險。這裡也就不一一列出。
通過上面的實踐可以看出我們平時使用的網路並不安全，部分開發者忽視證書校驗，或對證書異常處理不當，導致本來十分有效LTS失去原本的防禦能力。
改進
還是強調下，個人對於上面提到的2款App（知乎，360瀏覽器）並沒有惡意，只是藉此說明下當前網路大環境下確實存在的一些安全風險。
也希望2款APP的相關開發者看到後，可以及時改進，為使用者提供更安全的使用環境。
以上實踐測試環境（大家可以此重新上面的效果）
- 手機：
iphone6（10.3.3） ，iphone6s（11.3.1），iphone8 plus（11.2.1） - 伺服器：
CentOS（7.3）nginx（1.10.3） - 以上測試的2款應用均是蘋果版本的
APP - 知乎 （4.34.1）
- 360手機瀏覽器（4.0.10）
上述中間人攻擊實踐中使用到了Fiddler及FreeHttp外掛僅是為了方便控制及除錯中間人攻擊的狀態，實際操作中並不需要Fiddler，也就是說你的手機不需要連線任何代理，因為往往流量的劫持發生在更隱蔽的網路節點中，如鏈路中的網路裝置完全可以在無感的情況下將經過自己的流量先轉發到中間人伺服器,或者這種劫持也可能由DNS解析引起，您可以嘗試修改host檔案模擬dns劫持將目標域名指向中間人伺服器同樣可以得到上面的結果。
事實上ARP欺騙，WPAD劫持，DNS劫持，BGP路由劫持，都會為這種中間人攻擊創造條件（作為網路裝置的控制者實施起來就更容易了，所以不要連線不認識的wifi熱點，當然對於網路運營商我們也只能選擇相信）
ssltrip2可以通過arp欺騙篡改響應頁面內容，將https降級為http做劫持，曲線救國。這種攻擊利用的是很多網站並沒有關掉http訪問，而是在服務端將首頁從http跳到https，給了攻擊者一個http響應做突破口。不過這種攻擊也可以防禦，啟用hsts和pre load就行了，讓攻擊者找不到任何http的機會。
開發者只要正確的在所在平臺的底層TLS庫中開啟證書校驗，並對異常證書做合理處理，HTTPS還是相對安全的。
以上內容僅做交流，請勿用於實際網路攻擊。