原文應該有圖片存在，但是由於網路原因無法顯示，所以本文中沒有這些圖片，文章最後幾個連結很重要

mitmproxy一個互動式，相容https的中間人http代理，帶控制檯介面

mitmdump類似與tcpdump,是http版本的，哈哈,也就是mitmproxy的命令列版本

libmproxy,是mitmproxy依賴庫

功能
竊聽　http請求和響應,並可以修改他們
儲存　完整的http會話,供以後回放或者分析
回放　客戶端的http會話
回覆　一個預先記錄的服務端響應
反向代理模式：轉發流量到指定的伺服器
透明代理模式
用Python指令碼化地改變http流量內容
動態生成　用來竊聽的SSL證書

HTTPS竊聽是如何實現的

子域名萬用字元SSL證書（wildcard SSL certificate，價格大約是每年125美元），能在一個IP地址上部署多個HTTPS子域名

UCC（統一通訊證書，Unified Communications Certificate）支援一張證書同時匹配多個站點，可以是完全不同的域名。

SNI（伺服器名稱指示，Server Name Indication）允許一個IP地址上多個域名安裝多張證書。

客戶端　連線到代理，作出類似下面的請求:

CONNECT example.com:443 HTTP/1.1

傳統上的代理，既不能檢視也不能操作SSL加密的資料流，所以一個CONNECT請求，簡單地要求代理在客戶端和伺服器之間開啟一個管道.代理只是一個服務者—-它根本就看不到雙向的轉發資料的具體內容．SSL連線的協商發生在管道之中,請求與響應對代理來說，都是透明的(opaque)

MITM 代表Man-In-The-Middle,用這個過程我們可以截獲理論上透明的資料流,基本的思想是:

    假裝成客戶端想要的連線的伺服器．對伺服器又假扮成客戶端.我們站在中間位置，解碼雙方的流量．最有技巧的部分是，　CA(Certificate Authority )系統被設計成阻止這種中間人攻擊．允許第３方機構對伺服器的SSL證書進行簽名，驗證他們是否合法．如果簽名不匹配，或者來自於不信任的第３方,那麼安全的客戶端就會丟棄這個連結，拒絕下一步的處理．

    我們自己成為一個受信任的證書頒發機構是一個難點.mitmproxy包含了完整的CA實現,能夠生成竊聽證書．

   (哈哈，我明白了，https的第１個過程就是去驗證證書，但是mitm冒充了證書辦法機構，讓假的證書　也能通過客戶端的校驗)

為了讓客戶端行人這些證書，我們要在裝置上手動地　註冊　mitmproxy為一個可信的CA頒發結構．

難題１：遠端的主機名是什麼?

為了達到我們的陰謀,我們需要知道要假冒的證書的域名—客戶端將要驗證這個證書　是否屬於它將要連線的域名，如果不是，就會中止．Mitmproxy用了一個狡猾的機制來探知域名—-upstream certificate sniffing.

一旦我們看到CONNECT請求，我們將暫停會話的客戶端部分，初始化一個併發連線到伺服器，我們完成同伺服器的SSL握手，探測伺服器所用的證書．現在，我們就用上游的SSL證書中的Common Name來為客戶端生成一個假證書．瞧，我們現在有了正確的主機名，可以呈現給客戶端端了，即使它沒有被客戶端指定過

難題2: SAN(可替換的名稱)
有時候，證書的Common Name不是客戶端要連線的主機名．這是因為在SSL證書有一個Subject Alternative Name欄位，允許指定　任意數目的可選的域名．
如果客戶端期望的域名，同可選域名的其中一個匹配，客戶也會繼續處理．儘管域名同證書的Common Name不匹配．

從上游的的證書中抽解出CN,我們也取出SAN, 並把它新增到生成的假證書裡．

難題3: Server Name Indication
vanilla證書的一個最大限制就是，每個證書都要求它自己的IP地址．這意味著，你不能在很多域名共享一個IP的虛擬主機上使用　獨立的證書.
SSL和TLS協議的伺服器名稱指示擴充套件，就是為了應對IP的缺乏．

客戶端在SSL握手的開始，就指定遠端伺服器的名稱，它讓伺服器可以選擇一個正確的證書返回客戶端．

SNI打破了我們的上游證書偷窺過程，因為當我們連線伺服器時，不使用SNI,那麼我們就得到服務的一個預設的證書．

解決方法是，當客戶端連線過來，我們允許SSL握手繼續，直到SNI從客戶端傳送過來，我們就暫停會話，用從客戶端得到的SNI來初始化一個到伺服器的連線，來獲取正確的上游證書，然後從中抽解出CN和SANs

因為mitmproxy使用的SSL庫的限制，我們不能檢測一個連線　有沒有傳送一個SNI請求，以至於偷看上游證書太遲．
在實踐中，我們做一個vanilla的SSL連線到伺服器，先偷看到非SNI證書．如果客戶端傳送了一個SNI 提示，我們就丟掉這個連線．
如果你用tcpdump之類的東西檢視流量，就會發現當 SNI請求發出時，有兩個到伺服器的連線.第１個連線在SSL握手完成後，就立即關閉．
好在，這對實際的使用　沒有什麼不利的影響．

透明的HTTP代理

使用透明代理時，HTTPS連線直接在網路層轉給代理伺服器．客戶端什麼都不需要配置．很多時候，你不能改變客戶端的網路訪問行為proxy-oblivious

Android應用是一個常見的例子

為了達到這個目的，我們需要介紹兩個額外的元件．第１個就是重定向機制，它可以透明地重路由一個到網際網路上的伺服器的TCP 連線　到一個監聽中的代理伺服器．

這通常用跟代理伺服器在同一個主機上的防火牆來實現，比如Linux下的iptables, 或者OSX中的pf,一旦客戶端初始化了連線，　　它將作出一個普通的HTTP請求(注意，這種請求就是客戶端不知道代理存在)請求頭中沒有scheme(比如http://或者https://), 也沒有主機名(比如example.com)我們如何知道上游的主機是哪個呢？路由機制執行了重定向，但保持了原始的目的地址．

不同的路由機制有不同的檢視資料的方法，

mitmdump的使用

mitmdump -w outfile

證書預設儲存在~/.mitmproxy目錄

mitmproxy-ca.pem 　　　私鑰和證書

mitmproxy-ca-cert.pem  　　證書，這個用來分發到非windows平臺

mitmproxy-ca-cert.p12     證書的PKCS12格式，用於windwos

mitmproxy-ca-cert.cer      同pem, Android裝置需要這種格式的證書

 
CA用來動態生成假證書．因為你的瀏覽器不信任mitmproxy的CA,當你參觀一個新的SSL域名時，你應該可以看到SSL證書警告．

當你測試單個站點是，手動選擇接受bogus SSL證書，不是什麼太麻煩的事情．但是很多環境，你需要配置你的測試系統或者瀏覽器，信任mitmproxy的CA證書　作為一個簽名的root授權．

Firefox安裝方法

複製　~/.mitmproxy/mitmproxy-ca-cert.pem 　到目標裝置

Preference->Advanced->Encryption->View Certificates->Import

然後選擇mitmproxy-ca-cert.pem 　證書

勾選上 Trust this CS to identify web sites

Settings -> Security -> Credential Storage　然後選擇　Install from storage

 iptable設定

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

 啟用透明代理, 

mitmproxy -T --host

 Android上這樣設定

http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/

Android上證書匯入
上傳到網站，用瀏覽器下載就可以了

http://blog.kylemanna.com/android/2013/06/02/android-ca-certificates/

http://renxifeng.is-programmer.com/posts/34205.html

http://blog.sina.com.cn/s/blog_6916fad10101bqh9.html

http://blog.csdn.net/haijun286972766/article/details/6247675

注意
net.bridge.bridge-nf-call-iptables

sysctl -w
　net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

對於tap介面iptables貌似起作用了