前言
很早以前看過HTTPS的介紹，並了解過TLS的相關細節，也相信使用HTTPS是相對安全可靠的。直到前段時間在驗證https代理通道連接時，搭建了MITM環境，才發現事實並不是我想的那樣。由於部分應用開發者忽視證書的校驗，或者對非法證書處理不當，讓我們的網絡會話幾乎暴露在攻擊者面前。
下文會向大家展示的對IOS系統上2款常見的應用（知乎，360瀏覽器）進行MITM攻擊，獲取或篡改用戶數據。
基本介紹
中間人攻擊的基本介紹可能看這里（
https://zh.wikipedia.org/wiki/中間人攻擊）。大致是說一種在網絡中劫持會話的攻擊方案，如果只監聽流量稱之為被動網絡攻擊（passive network attack），如何攻擊者主動修改數據流稱之為主動網絡攻擊（active network attack）。
好在20幾年前Https就出現了，在保證會話安全的同時也能很好的抵御中間人攻擊（不過飄逸的應用開發者們總是能不經意的忽視這種保護）
網上對中間人攻擊的介紹還算多，不過具體到實踐的就相對要少很多（這里是指針對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/lulianqi/p/10428551.html#_label0_1可以在這里下載該插件），插件安裝好后直接按下面截圖配置即可（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熱點，當然對於網絡運營商我們也只能選擇相信）
開發者只要正確的在所在平台的底層TLS庫中開啟證書校驗，並對異常證書做合理處理，HTTPS還是相對安全的。
以上內容僅做交流，請勿用於實際網絡攻擊。