如何解密QUIC协议

QUIC协议是google首先提出的新一代基于UDP传输的协议，其主要目的是针对TCP传输的一些缺点进行改进，例如传输效率低，以及阻塞等。由于完全的替换现有的TCP，UDP这些传输层协议并不现实。看看微软的例子就知道，微软几年前就已经宣称不再维护升级windows XP，但是该系统的市场占有率依然很高。也就是说去颠覆现有的协议栈并不现实，因此google在UDP的基础上开发除了QUIC协议来替代基于TCP的传输，可以说QUIC协议融合了TCP的一些优点，比如说报文的确认机制，融合了SSL的优点，比如说数据的加密。最新的TLS1.3其实就是QUIC协议加密部分演变而来。

QUIC协议目前主要应用于youtube的传输过程中。移动端默认使用QUIC协议进行传输（QUIC协议不能使用，则会使用TCP+SSL传输），浏览器中可以设置开启QUIC协议，则会使用QUIC协议进行传输，如下图：

当然关于QUIC协议的内容，本文先不过多的讨论。本文所关注的重点在于QUIC层是加密，因此如何解密QUIC层的内容以有利于进一步的分析工作，是很重要的。同时解密也能够帮助我们理解QUIC的工作机制。

之于解密，我在前面的若干篇文中以及提及了很多，可以参考CSDN 村中少年这篇文章。主要是针对于HTTPS的解密，利用代理中间人获取密钥解密，当然wireshark也是可以读取浏览器存起来的密钥进行解密的，见这里。

但是对于QUIC协议来说，暂时没法通过代理来充当中间人；同时对于QUIC的密钥，像chrome以及Firefox都不支持像SSL那样保存会话的密钥（但是在chrome的论坛看到，是有人像Chrome提出过类似的建议的，但是目前最近版本还是不支持的），wireshark暂时没有支持QUIC 密钥的导入解密，因此通过这两种方式的机密就无法生效。但是chrome浏览器本身提供了一些工具支持对于QUIC的解密，如下图：

可以看到图中捕获了三条UDP流，点开其中一个如下图：

可以看到浏览器把加密的报文都以解密的形式呈现出来了，包括packet_number ,size，quic流的结束标志以及GET方法等信息。有了上行GET的大小信息就能够和使用wireshark捕获的PCAP文件中的报文对应上了，依据就是上行的大小和UDP层提供长度的对应，这对于分析一些数据的传输规律是极为有用的。

当然上述只是解密浏览器端的QUIC协议，诸如像android以及IOS等移动端还是没有办法进行解密的（我在以前的文章有利用中间人解密移动端的HTTPS，可以参考下），但是可以从浏览器端的QUIC入手去学习QUIC的传输机制以及传输规律还是很有帮助的。

本文为CSDN村中少年原创文章，转载记得加上小尾巴偶，博主链接这里。