Web 安全是一项系统工程，任何细微疏忽都可能导致整个安全壁垒土崩瓦解。拿 HTTPS 来说，它的「内容加密、数据完整性、身份认证」三大安全保证，也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全，其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理，浅谈一下 HTTPS 的安全风险。
Man-in-the-middle（中间人，简称为 MITM），能够与网络通讯两端分别创建连接，交换其收到的数据，使得通讯两端都认为自己直接与对方对话，事实上整个会话都被中间人所控制。简而言之，在真正的服务端看来，中间人是客户端；而真正的客户端会认为中间人是服务端。
实现中间人攻击有各种各样的手段，这里不展开讨论。一些常见的 HTTP/HTTPS 抓包调试工具，都是通过创建本地 Proxy 服务，再修改浏览器 Proxy 设置来达到拦截流量的目的，他们的工作原理与中间人攻击一致。我用过的这一类工具有：Fiddler、Charles 和 whistle。我在「HTTP 代理原理及实现（一）」一文中介绍的 HTTP 普通代理，扮演的就是 HTTP 中间人角色。
本文主要讨论 HTTPS 中间人，简单示意如下：
Server<--->LocalProxy<--->Browser
^^
HTTPS(1) HTTPS(2)
上述 HTTPS(1) 连接，是中间人冒充客户端，与服务端建立的连接，由于 HTTPS 服务端一般不认证客户端身份，这一步通常没有问题。而对于 HTTPS(2) 连接来说，中间人想要冒充服务端，必须拥有对应域名的证书私钥，而攻击者要拿到私钥，只能通过这些手段：
去网站服务器上拿；
从 CA 处签发证书；
自己签发证书。
要防范前两点，需要网站做好各个方面的安全防护，从主机安全到网站安全（避免私钥被盗），从域名解析安全到域名邮箱安全（避免攻击者重签证书）。而攻击者自己签发的证书，无法通过系统内置根证书的验证，默认无法用于中间人攻击。
对于 Fiddler 这一类调试工具来说，能够解密 HTTPS 流量的关键在于他们会往系统受信任的根证书列表导入自己的证书，这样他们的自签证书就能被浏览器信任。进入 Fiddler 设置中的「HTTPS」Tab，勾选相关功能后，就可以顺利解密和修改 HTTPS 流量。这时在浏览器中可以看到这样的证书链：
fiddler root
RSA Private Key我在「使用 Wireshark 调试 HTTP/2 流量」这篇文章中写到：Wireshark 的抓包原理是直接读取并分析网卡数据，要想让它解密 HTTPS 流量，有两个办法：
如果你拥有 HTTPS 网站的加密私钥，可以用来解密这个网站的加密流量；
某些浏览器支持将 TLS 会话中使用的对称密钥保存在外部文件中，可供 Wireshark 加密使用。
那篇文章介绍了第二种方案，本文简单介绍第一种。
打开 Wireshark 的 SSL 协议设置，参考下图，把 IP、端口、协议和证书私钥都配上（私钥必须存为 PEM 格式）：
wireshark ssl config
然后访问私钥对应的网站，可以看到流量已被解密：
decrypt http1 over tls
截图中的加密数据是以 HTTP/1 传输的，这种方式能解密 HTTP/2 流量吗？结论是：不能！具体原因下面慢慢分析。
我们知道，TLS 握手阶段需要进行密钥交换和服务端认证这两个重要的操作，密钥交换是为了在不安全数据通道中产生一个只有通信双方知道的共享密钥 Premaster Secret，进而生成 Master Secret 以及后续对称加密 Session Key 和 MAC Key。而客户端进行服务端认证的目的是确保连接到拥有网站私钥的合法服务器。
最常见的密钥交换方式是 RSA，下面这张图清晰的描述了这个过程：
ssl handshake rsa
Client Random 和 Server Random 明文传输，中间人可以直接查看。客户端生成 Premaster Secret 后，用服务端证书公钥加密后发送，如果服务端拥有对应的私钥，就可以成功解密得到 Premaster Secret。这时，客户端和服务端拥有相同的 Client Random、Server Random 和 Premaster Secret，可以各自算出相同的后续所需 Key。