关于https的一点想法

关于https，我一直是心存疑惑的，我知道https相比于http，有两个优点。一是多了认证过程，知道通信双方是不是正经的通信双方，二是多了加密过程，通信双方的交流信息是被加密的。

但是对于具体的内部流程，一直比较含糊，所以今天用burpsuite时突然觉得好奇，burpsuite截获https报文时为什么可以读取到https内部的信息，而wireshark嗅探得到的却是密文，同样都是本地报文的抓取，有啥不一样。

事实上，burpsuite是作为代理来达到捕获的目的，wireshark是通过监听网卡来达到捕获的目的。而burpsuite作为代理，安装的时候是需要在浏览器上配置证书的。

所以要想了解这个问题，需要掌握https的具体通信过程。

https的通信过程

引用下阮一峰老师文章SSL/TLS协议运行机制的概述中的几句：

1. 客户端向服务器端索要并验证公钥
2. 双方协商生成"对话密钥"
3. 双方采用"对话密钥"进行加密通信。

这里有几个问题，一是如何如何验证公钥的可靠性，即不是被中间人篡改过；二是通信双方如何协商“对话秘钥”。

关于第一个问题，首先要知道数字证书和数字签名的概念。这里的公钥其实就是数字证书中的一部份内容，数字证书有可信任机构CA颁布，包含的内容有：签发者；证书用途；申请者的公钥；申请者的加密算法；申请者的HASH算法；证书的到期时间等。

当客户端发起请求之后，服务端会对证书进行数字签名，引用车小胖在问题下的回答，这个过程描述为：

把证书以上内容做一次HASH，得到一个固定长度（比如128位的HASH，然后再用CA的私钥加密，就得到了数字签名。

这个添加了数字签名的证书由服务端发送给浏览器，浏览器会用本地的CA的公钥进行解密，查看HASH值，即可知道是否被人篡改过。这个CA公钥的获得应该是本地内置了或者安装过的。

第二个问题，协商算法的过程似乎是不止一种，网上大多数的是经典的RSA算法，过程可以描述为：

1. 客户端向服务端发起请求
2. 服务端返回证书（公钥）
3. 客户端生成对称密钥，并将其用公钥加密，发送给服务端。
4. 服务端用自己的私钥解密，得到对称密钥。
5. 两端愉快地用对称密钥加密信息进行交流。

但是在阮一峰的文章中，采用的是三个随机数的方式，具体可以看他的文章，链接在前面；而在车小胖的回答中用到的是DH算法。在文章扫盲 HTTPS 和 SSL/TLS 协议[3]：密钥交换（密钥协商）算法及其原理中总结了几种算法的异同。这里就不再累述。

通过wireshark抓包，访问淘宝的过程如下：

image.png

访问百度的过程如下：

image.png

报文内部都有ECDH字段，所以目前流行的协商密钥算法应该是ECDH算法。

回到问题

回到原来的问题，burpsuite作为代理中间人，实际上是实现了客户端和服务端双向的SSL通信，所以这里需要满足的条件是，客户端信任burpsuite的证书，burpsuite产生自己的公钥私钥。证书的话需要手动配置浏览器的信任，公钥私钥的话，是有工具可以生成的。

参考

SSL/TLS协议运行机制的概述
问题
细说中间人攻击(一)
扫盲 HTTPS 和 SSL/TLS 协议[3]：密钥交换（密钥协商）算法及其原理