很早以前看過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通道是與我們的伺服器建立的，即表示我們可以任意的處理這些流量，随時都可以進行主動網絡攻擊。
所有準備工作做完了我們就可以看下中間人攻擊的效果了
當然正常情況下，我們的網絡安全肯定不會這麼脆弱，是以暫時我們在下面看到的是在一切正常的情況下，看浏覽器是如何借助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那麼風險随時都在。
現實中我們被手機陪伴的時間明顯更多，我們下面來看下手機上移動應用是否能抵禦這種中間人攻擊。
許多應用使用HTTPS與後端進行通信，這種做法在系統程式，網站及移動應用中非常常見。不幸的是，應用開發者往往沒有正确的對證書進行校驗，這樣系統實際對攻擊者敞開了懷抱。
QA流程應該包括證書校驗方面的測試。
首先我們将手機連上Fiddler代理（注意這裡我們不需要讓手機安裝或信任任何第三方證書）
我們嘗試着如日常生活一樣使用手機（注意這裡測試使用的都是IOS上APP）
大部分應用出現了無法通路，彈出式安全提示等反應
不過不幸的是仍然有一些應用無視了證書的保護，直接與危險的中間人伺服器建立了連接配接，并向使用者正常的顯示了頁面等資料。
下面列幾個代表性強的APP進行說明 （這裡不是特意選擇這些APP，隻是我手機中正好安裝有，而且個人認為這些APP大家也比較常用）
可以清楚看到知乎是完全無視了證書不比對的錯誤，與沒有受到MITM時表現是一樣的，正常通路，正常送出資料。但事實卻是所有流量都是通過中間人伺服器轉發到知乎的，中間伺服器解密了所有流量，并且可以對其進行篡改。更糟的是這一切發生的時候，使用者是完全不知情的。簡單的說就是當您在使用知乎APP浏覽或發帖時，網絡節點中的任何别有用心的人都是可以擷取您在浏覽的内容，并對其進行修改。（這樣的描述一點都不誇張，後面會說明實際MITM中，也不會需要您的手機提前連接配接Fiddler代理，有許多可行且更隐秘的方式可以将流量引入中間人伺服器。如果應用不能識别到分享，就會跟上面描述的情況一樣）
其實某款特定APP由于自身安全問題不能抵禦MITM，最多也隻會影響到自己的APP及自己的使用者，不過浏覽器如果出現這種問題就會對使用者所有浏覽的網站都有影響
特别是以安全為一大賣點的360，其自家浏覽器的安全政策讓人無法了解
上面的截圖來自使用360浏覽器分别浏覽baidu及apple的情況，可以看到使用360手機浏覽器浏覽網頁（開啟https的網站），在受到MITM時隻有一個不起眼的變化，那個原本應該是綠色的小盾牌變成了灰色，并且沒有向使用者進行任何詢問，直接就建立了不安全的SSL通道，後面的情況就很驚悚了，所有使用360手機浏覽器浏覽的内容全部被中間人伺服器劫持。
一開始自己也并不相信360手機浏覽器會直接無視證書錯誤，不向使用者詢問。特意找了另一台沒有安裝過360手機浏覽器的手機（iphone6），在AppStore裡下載下傳了新版本的360手機浏覽器測試，結果是一樣的，除了那個不起眼的灰色小盾牌完全無視了證書域名不比對的錯誤。（順便提一下上面的知乎也一樣，都用新手機測試過，的确有安全問題）
當然我在自己手機了不隻發現上面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還是相對安全的。
以上内容僅做交流，請勿用于實際網絡攻擊。