Fiddler能分析HTTPS流量意味著HTTPS協議不安全？
前幾天有個同學在公眾號問了我一個問題，涉及到Fiddler分析HTTPS流量的問題，雖然對Fiddler不太瞭解，但一看是HTTPS問題，我還是非常感興趣的，因為嗅探軟體的工作原理是相通的，基於現有知識分析一個未知的問題是非常有趣的事情，所以我放下工作，簡單瞭解了下，並有了一個相對滿意的解答，然後寫了此文，從問題分析到文章完成總共花了不到一個小時。
這是一次全新的寫作體驗，相比以前，我總是四平八穩的分析、論證、撰寫，產出一篇文章需要很久，而這次完全是“衝動式”的寫作過程，所以文章難免有錯誤，再加上我對Fiddler不太瞭解，會暴露更多的錯誤，這一點請大家瞭解，同時本文不涉及任何的實踐，僅僅從理論上進行分析論證。
廢話了那麼多，那麼到底是什麼問題呢？核心有兩點:
- Fiddler是否能夠分析、篡改HTTPS流量？如果能，原理是什麼？
- 如果能夠分析、篡改HTTPS流量，是否說明HTTPS協議設計有漏洞？
本質上寫這篇文章主要原因是很多人對HTTPS協議的誤解，總覺得它不安全，所以我先反駁下，這是錯誤的一種觀點。
（1）HTTPS協議從設計上是沒有問題的，但歷史上HTTPS實現確實出現過一些漏洞（比如 OpenSSL 心臟滴血），但這是工程實現問題，不是協議問題。
（2）早期的HTTPS協議（其實是TLS協議）安全性不是很高，後續版本經過迭代解決了很多問題，理論上HTTPS服務部署者可以廢棄低版本的TLS協議，但由於萬惡的低版本客戶端（比如 xp系統下的IE瀏覽器）太多了，為了相容它們，HTTPS服務部署者只能在安全性上做一個折中。
（3）HTTPS協議是一個典型的B/S應用協議，它的安全性不僅僅取決於HTTPS協議的伺服器端，也取決於客戶端（典型的就是瀏覽器），如果客戶端在實現的時候出現一些問題，也可能導致HTTPS協議漏洞。
（4）web安全（當然也包括其他領域）是一個複雜的問題，HTTPS協議安全只是Web安全領域的一部分，它只是保證你流量不被劫持、偽造、篡改，可web的執行由於JavaScript的存在，仍然會出現安全漏洞，記住web安全和HTTPS安全不是一回事。
（5）不道德的行為，對於HTTPS應用來說，如果一個CA機構沒有品行，惡意簽發證書，那麼HTTPS的安全性也沒有保證，這你能怪HTTPS協議嗎?某種程度上確實應該怪它，但我們必須瞭解不安全的根本原因，PKI安全是一個非常複雜的問題，如果不構建一個安全標準，即使有了HTTPS協議，也不見得就安全。
又自言自語說了一大通，現在讓我們回到本文的主題，Fiddler能夠解密HTTPS流量，它的基本實現原理來源於“中間人”方法，通過下圖和對圖的描述，同學們就會清楚了。
圖1
（1）假設在Chrome瀏覽器中配置了Fiddler代理，然後在瀏覽器中訪問 ofollow,noindex">https://www.test.com ，目的是為了查詢自己的工資，由於所有的HTTPS流量都會經過Fiddler代理，瀏覽器向Fiddler發起TLS握手。
（2）Fiddler代理接收到TLS握手請求，為 www.test.com 生成一張證書（證書中包含該主機），該證書用 Fiddler根證書 進行簽名，然後將 www.test.com 證書傳送給瀏覽器。
（3）瀏覽器校驗完證書後（該證書包含的主機和待訪問的主機相同），最後和伺服器端協商出一致的對稱加密演算法的金鑰（ MasterKeyA ）。
（4）TLS握手完成後，瀏覽器使用MasterKeyA加密應用層資料（即查詢自己工資）傳送給Fiddler。
（5）Fiddler使用MasterKeyA解密出應用層資料（即知道瀏覽器想幹啥），然後以客戶端的身份和 www.test.com 建立TLS連線，並協商出一致的對稱加密演算法的金鑰（ MasterKeyB ），然後對應用層資料（即查詢自己工資）使用MasterKeyB加密併發送給 www.test.com 伺服器。
（6） www.test.com 伺服器使用MasterKeyB解密出Fiddler（實際上是Chrome的）傳送的資料（即查詢自己工資），從資料庫中查詢出工資（假設是100元）後，然後使用MasterKeyB加密後傳送給Fiddler。
（7）Fiddler對100元使用MasterKeyA加密，然後傳送給Chrome瀏覽器，瀏覽器使用MasterKeyA解密出就得到了自己的工資。
這就是大概的原理，並沒有太多的技術含量，就是中間人方法，很多人說“你說的不對，如果如此簡單，那麼任何一個閘道器或路由器就能夠輕鬆解密HTTPS流量了”。
說的沒錯，中間人方法（中間人攻擊）在HTTPS協議中實際上是行不通的，原因在於Chrome瀏覽器會校驗證書的合法性。假設 www.test.com 使用let’s encrypt根證書籤名，由於瀏覽器在自己的 可信任根證書列表 中集成了 let’s encrypt根證書 ，在TLS握手的時候發現 www.test.com 證書是由let’s encrypt簽名的，使用let’s encrypt根證書的公鑰進行驗籤，一旦通過，代表該證書合法。
如果任何的 閘道器或路由器 使用中間人方法截獲了HTTPS流量，偽造一張證書（比如 www.test.com 證書），該證書必然也由一張根證書籤名，可這張根證書大概率Chrome瀏覽器沒有整合在自己的可信任根證書列表中，所以根本不會信任它，從而彈出一個提示“該證書不合法，HTTPS握手失敗”。
有點明白了嗎？那為啥Fiddler作為一個代理（中間人）能夠解密HTTPS流量呢？因為它的根證書Chrome沒有整合在自己的可信任根證書列表中（一個CA機構想將自己的根證書整合到瀏覽器的可信任根證書列表中需要經過嚴格的審計），它怎麼做到的？
原因在於在配置Fiddler的時候（以下只考慮Windows系統），Fiddler會將自己的根證書放入到Windows可信任根證書庫中，Chrome使用Windows的根證書庫，所以Chrome就信任了Fiddler的根證書，從而能夠解密HTTPS流量了。
總結下，如果要使用Fiddler解密HTTPS流量，必須能夠控制 配置Fiddler代理的機器 （在除錯的機器上安裝Fiddler根證書），這是很重要的一個前提，如果你作為一個黑客能夠控制別人的電腦了，此時就不要討論這臺電腦的HTTPS流量被解密了，安全都是相對的。
最後用一張圖簡單回顧下Fildder是如何解密的：
圖2
大概原理講完了，很多人覺得Fiddler解密HTTPS配置太複雜了，原因在於有些時候可能需要自己下載Fiddler的根證書並整合到客戶端（比如瀏覽器）或作業系統的可信任根證書列表中，比如：
- 你想解密HTTPS流量的機器並沒有安裝Fiddler，只是配置了它的代理。
- 像Firefox沒有使用Windows的根證書庫，它使用自己的NSS根證書。
如果你需要自己配置Fiddler根證書，那麼下面一些文章適合你閱讀：
- 在windows系統中，雙擊Fiddler根證書（.crt字尾），就會有圖形化的安裝介面，從而完成配置。
- 在Windows系統中，IE和Chrome預設是使用Windows根證書的，沒有特殊需要無需單獨配置，如果想要在Chrome中單獨配置Fiddler根證書，可以參考 如何讓chrome信任自簽名證書？
- 在Firefox中，如果想配置Fiddler根證書，可以參考 在firefox中更新證書的幾種方式
如果根證書驗證簽名沒有理解，或者想了解更多的PKI知識，可以參考我的書《深入淺出HTTPS：從原理到實戰》。
【這篇文章於2018-10-14號發表於公眾號,地址 https://mp.weixin.qq.com/s/v2FvcJd_SDob19ToXxLWIA ，也可以關注我的公眾號（ID：yudadanwx，虞大膽的嘰嘰喳喳）】