前言

在渗透测试过程中，必不可少的操作就是使用BurpSuite、Fildder等抓包工具对应用程序的数据包进行拦截、观察和篡改。那么问题来了——对于使用HTTPS协议的站点，在BurpSuite中拦截到的数据包为何也是“明文传输”？如下图所示。

从大神那里获得解答：

（1） BurpSuite能抓到HTTPS协议的“明文数据”是因为BurpSuite在本地浏览器安装了自己的证书，作为中间人的它分别建立起了“客户端->代理服务器”、“代理服务器->服务端”两段HTTPS通道，BurpSuite获得Client消息后先解密后再重新加密，然后代替客户端发给服务端，这个过程中BurpSuite自然能获得明文。

（2） 但是如果使用WireShare来单纯监听、嗅探HTTPS协议的数据包的话，我们就会看到TCP携带的Data都是密文，是无法拿到明文数据的。

WireShark抓包

接下来当然是使用WireShare监听数据并观察分析下，先简单说下WireShare的基本使用。

首先开启WireShark并配置受监听的网卡：

选择正在使用的网卡，双击WLAN开始监听：

电脑中开启浏览器或其他应用的时候都会有流量产生，有流量产生就会被WireShark捕捉到。上图为刚刚开启WireShark后的捕捉状态，会抓到大量各种各样的流量，稍后我们会进行过滤操作。

HTTP站点

使用合天网安实验室的登录页面作为观察对象。

在CMD中Ping域名，获得站点IP地址58.20.54.226：

在WireShark中设置过滤规则“ip.dst==58.20.54.226”，发现登录请求传输的账号密码信息：

也可以选择资源为POST /sessions HTTP/1.1的流量然后鼠标右键选择追踪流->TCP流，可以看到用户名和密码等敏感信息可以被嗅探：

查看前端代码，可发现该HTTP站点确实对账户密码做了前端加密后再进行传输：

HTTPS站点

看完上面HTTP站点的数据在WireShark中“裸奔”，接下来看看HTTPS站点是不是也如此。

选用站点“墨者学院”作为观察对象：

在WireShark中设置过滤规则“ip.dst==113.200.16.234”，可发现HTTP站点的流量均给出了具体的请求资源地址（如上面的POST /sessions HTTP/1.1），而HTTPS站点传输的时候只提示为“Application Data”：

继续选择任意协议为TLSv1的流量后右击选择追踪流->TCP流，发现数据均经过加密，根本看不懂：

解密HTTPS数据

HTTPS协议使用了对称加密，客户端拥有并存储了对称加密的会话密钥，浏览器在接收到服务端发送回来的密文数据之后，会使用存储在本地的秘钥对数据进行解密。那么我们通过WireShark监听到的HTTPS站点的密文能否依靠此密钥进行自动解密？答案是——可以。

接下来我们来实际操作并验证下：

1、以windows系统+Chrome浏览器为例，首先要导出浏览器存储的密钥，通过计算机属性——高级系统设置——环境变量，新建一个变量名“SSLKEYLOGFILE”的变量，变量值是导出的密钥具体文件地址。2、设置后可以通过重启Chrome浏览器打开任意一个HTTPS网址，此时查看变量值对应路径，密钥成功导出到本地啦，已经生成sslkey.log文件：

3、现在可以将密钥导入到Wireshark了，具体路径如下：菜单栏—>编辑—>首选项—>Protocols—>TLS/SSL（选择SSL还是TLS请根据实际情况）：

4、配置完成，来看下最终的实际效果（此处同样使用上文中“墨者学院”HTTPS站点作为测试对象，其初始的加密数据包状态可翻看前文）：

5、对比一下文章开头BurpSuite拦截到的数据包：

最后，我们可以得知BurpSuite拦截HTTPS站点可获得明文数据包，并非因为HTTPS站点跟HTTP站点一样进行“裸奔”，而是BurpSuite代理服务器作为中间人，对HTTPS站点的数据包进行了解密。