注册
登录
| 关键词： 随机数 加密 客户端 握手 会话 服务器 key 一个 数据 baidu |
最近，有位读者问起一个奇怪的事情，他说他想抓一个baidu.com的数据包，体验下看包的乐趣。 但却发现“抓不到”，这就有些奇怪了。 我来还原下他的操作步骤。 首先，通过ping命令，获得访问百度时会请求哪个IP。 从上面的结果可以知道请求baidu.com时会去访问39.156.66.10。 于是用下面的tcpdump命令进行抓包，大概的意思是抓eth0网卡且ip为39.156.66.10的网络包，保存到baidu.pcap文件中。 此时在浏览器中打开baidu.com网页。或者在另外一个命令行窗口，直接用curl命令来模拟下。 按理说，访问baidu.com的数据包肯定已经抓下来了。 然后停止抓包。 再用wireshark打开baidu.pcap文件，在过滤那一栏里输入http.host == "baidu.com"。 此时发现，一无所获。  这是为啥？ 到这里，有经验的小伙伴，其实已经知道问题出在哪里了。 为什么没能抓到包这其实是因为他访问的是HTTPS协议的baidu.com。HTTP协议里的Host和实际发送的request body都会被加密。 正因为被加密了，所以没办法通过http.host进行过滤。 但是。 虽然加密了，如果想筛选还是可以筛的。 HTTPS握手中的Client Hello阶段，里面有个扩展server_name，会记录你想访问的是哪个网站，通过下面的筛选条件可以将它过滤出来。  此时选中其中一个包，点击右键，选中Follow-TCP Stream。  这个TCP连接的其他相关报文全都能被展示出来。  从截图可以看出，这里面完整经历了TCP握手和TLS加密握手流程，之后就是两段加密信息和TCP挥手流程。 可以看出18号和20号包，一个是从端口56028发到443，一个是443到56028的回包。 一般来说，像56028这种比较大且没啥规律的数字，都是客户端随机生成的端口号。 而443，则是HTTPS的服务器端口号。
粗略判断，18号和20号包分别是客户端请求baidu.com的请求包和响应包。 点进去看会发现URL和body都被加密了，一无所获。 那么问题就来了。有没有办法解密里面的数据呢？ 有办法。我们来看下怎么做。 解密数据包还是先执行tcpdump抓包 然后在另外一个命令行窗口下执行下面的命令，目的是将加密的key导出，并给出对应的导出地址是/Users/xiaobaidebug/ssl.key。 然后在同一个命令行窗口下，继续执行curl命令或用命令行打开chrome浏览器。目的是为了让curl或chrome继承这个环境变量。 此时会看到在/Users/xiaobaidebug/下会多了一个ssl.key文件。 这时候跟着下面的操作修改wireshark的配置项。  找到Protocols之后，使劲往下翻，找到TLS那一项。  将导出的ssl.key文件路径输入到这里头。  点击确定后，就能看到18号和20号数据包已经被解密。  此时再用http.host == "baidu.com"，就能过滤出数据了。  到这里，其实看不了数据包的问题就解决了。 但是，新的问题又来了。 ssl.key文件是个啥？ 这就要从HTTPS的加密原理说起了。 HTTPS握手过程HTTPS的握手过程比较繁琐，我们来回顾下。 先是建立TCP连接，毕竟HTTP是基于TCP的应用层协议。 在TCP成功建立完协议后，就可以开始进入HTTPS阶段。 HTTPS可以用TLS或者SSL啥的进行加密，下面我们以TLS1.2为例。 总的来说。整个加密流程其实分为两阶段。 第一阶段是TLS四次握手，这一阶段主要是利用非对称加密的特性各种交换信息，最后得到一个"会话秘钥"。 第二阶段是则是在第一阶段的"会话秘钥"基础上，进行对称加密通信。  我们先来看下第一阶段的TLS四次握手是怎么样的。 第一次握手：
第二次握手：
第三次握手：
第四次握手：
四次握手中，客户端和服务端最后都拥有三个随机数，他们很关键，我特地加粗了表示。 第一次握手，产生的客户端随机数，叫client random。 第二次握手时，服务器也会产生一个服务器随机数，叫server random。 第三次握手时，客户端还会产生一个随机数，叫pre_master_key。 这三个随机数共同构成最终的对称加密秘钥，也就是上面提到的"会话秘钥"。  你可以简单的认为，只要知道这三个随机数，你就能破解HTTPS通信。 而这三个随机数中，client random 和 server random 都是明文的，谁都能知道。而pre_master_key却不行，它被服务器的公钥加密过，只有客户端自己，和拥有对应服务器私钥的人能知道。 所以问题就变成了，怎么才能得到这个pre_master_key？ 怎么得到pre_master_key服务器私钥不是谁都能拿到的，所以问题就变成了，有没有办法从客户端那拿到这个pre_master_key。 有的。 客户端在使用HTTPS与服务端进行数据传输时，是需要先基于TCP建立HTTP连接，然后再调用客户端侧的TLS库（OpenSSL、NSS）。触发TLS四次握手。 这时候如果加入环境变量SSLKEYLOGFILE就可以干预TLS库的行为，让它输出一份含有pre_master_key的文件。这个文件就是我们上面提到的/Users/xiaobaidebug/ssl.key。  但是，虽然TLS库支持导出key文件。但前提也是，上层的应用程序在调用TLS库的时候，支持通过SSLKEYLOGFILE环境触发TLS库导出文件。实际上，也并不是所有应用程序都支持将SSLKEYLOGFILE。只是目前常见的curl和chrome浏览器都是支持的。 SSLKEYLOGFILE文件内容再回过头来看ssl.key文件里的内容。 这里有三列。 第一列是CLIENT_RANDOM，意思是接下来的第二列就是客户端随机数，再接下来的第三列则是pre_master_key。 但是问题又来了。 这么多行，wireshark怎么知道用哪行的pre_master_key呢？ wireshark是可以获得数据报文上的client random的。 比如下图这样。  注意上面的客户端随机数是以 "bff63bbe5"结尾的。 同样，还能在数据报文里拿到server random。  此时将client random放到ssl.key的第二列里挨个去做匹配。 就能找到对应的那一行记录。  注意第二列的那串字符串，也是以 "bff63bbe5"结尾的，它其实就是前面提到的client random。 再取出这一行的第三列数据，就是我们想要的pre_master_key。 那么这时候wireshark就集齐了三个随机数，此时就可以计算得到会话秘钥，通过它对数据进行解密了。 反过来，正因为需要客户端随机数，才能定位到ssl.key文件里对应的pre_master_key是哪一个。而只有TLS第一次握手（client hello）的时候才会有这个随机数，所以如果你想用解密HTTPS包，就必须将TLS四次握手能抓齐，才能进行解密。如果连接早已经建立了，数据都来回传好半天了，这时候你再去抓包，是没办法解密的。 总结
|
| 本文出处： https://www.toutiao.com/article/7165779772457435659/ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
