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）假设在Chrome浏览器中配置了Fiddler代理，然后在浏览器中访问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是如何解密的：

大概原理讲完了，很多人觉得Fiddler解密HTTPS配置太复杂了，原因在于有些时候可能需要自己下载Fiddler的根证书并集成到客户端（比如浏览器）或操作系统的可信任根证书列表中，比如：

• 你想解密HTTPS流量的机器并没有安装Fiddler，只是配置了它的代理。

• 像Firefox没有使用Windows的根证书库，它使用自己的NSS根证书。

如果你需要自己配置Fiddler根证书，那么下面一些文章适合你阅读：

• 在windows系统中，双击Fiddler根证书（.crt后缀），就会有图形化的安装界面，从而完成配置。

• 在Windows系统中，IE和Chrome默认是使用Windows根证书的，没有特殊需要无需单独配置，如果想要在Chrome中单独配置Fiddler根证书，可以参考 如何让chrome信任自签名证书？

• 在Firefox中，如果想配置Fiddler根证书，可以参考 在firefox中更新证书的几种方式

如果根证书验证签名没有理解，或者想了解更多的PKI知识，可以参考我的书 《深入浅出HTTPS：从原理到实战》 。

本文也提到了let’s encrypt，它是全球最大的免费CA机构，可以让你无需考虑证书成本，而且它的功能已经和传统CA机构差不多了，比如也支持SAN通配符证书，但由于它的证书默认90天过期，所以需要定时更新，如果你想使用通配符证书且想自动更新，可以参考我写的工具，使用非常简单，Github地址是https://github.com/ywdblog/certbot-letencrypt-wildcardcertificates-alydns-au，或者点击文末“阅读原文”。