如果你想系统掌握 TLS 协议的细节，了解客户端和服务器消息的交互，非常好的学习工具就是 Wireshark，Wireshark 能够分析所有 TCP/IP 协议流量，自然也包括 TLS 协议。
最近想系统的解剖 TLS 1.3 协议的细节，所以就用到了这个工具考虑到 TLS 1.3 协议还没有广泛使用，第一个问题就是 Wireshark 是否已经支持 TLS 1.3 协议的分析呢？这篇文章就是为了解释这个问题的，核心目的就是“通过那些工作，促使 Wireshark 能够分析 TLS 1.3 协议流量”。再次强调，这篇文章不是告诉你“TLS 1.3 协议工作原理”。
在解释之前，先针对几个核心问题进行说明：
· TLS 1.2 协议和 TLS 1.3 协议之间的差异非常的大，而且无法向下兼容，所以 Wireshark 必须根据 TLS 1.3 协议标准重新开发解析器，也就是说，如果你的 Wireshark 版本太老，根本无法分析 TLS 1.3 协议。
· 如果你从没使用 Wireshark 解密 TLS 流量（比如 TLS 1.2 协议），那么这篇文章同样适合你。
· 在介绍之前，最好搭建一个支持 TLS 1.3 协议的网站，而且浏览器（比如 Chrome）也能支持该版本。具体可参考我的上一篇文章《让Nginx快速支持TLS1.3协议》。
· 这篇文章不是告诉你 TLS 1.3 协议的交互细节，只是告诉你，如何搭建一个分析 TLS 1.3 协议的 Wireshark 运行环境。
Wireshark 2.4 不能分析 TLS 1.3
由于 TLS 1.2 协议和 TLS 1.3 协议之间的差异非常的大，子消息之间的解析是不兼容的，所以如果你的 Wireshark 版本是 2.4，那么无法分析 TLS 1.3 ，因为它不知道子消息代表的含义。
具体查看下图：
wireshark_1.png
<center>图1：Wireshark 不能分析 TLS 1.3 协议</center>
通过示例图可以看出，Wireshark 2.4 根本不认识 TLS 1.3 协议版本，认识的最高版本是 TLS 1.2。
Wireshark 能够分析的 TLS 1.3 版本
通过 Wireshark 的 relnotes，没有清晰的说明那个版本开始支持 TLS 1.3，只是在 Wireshark 2.4.4 版本提到 TLS/SSL 版本有过修改。
查看邮件组（日期：2017.01），有关键的引用：
If you want to download a WorkInProgress version of Wireshark that supports TLS1.3 (latest >version of draft -18 only!). Please go to:
https://www.wireshark.org/download/automated/
THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!
从中可以看出 2017.01 以后的 Wireshark 版本开始支持 TLS 1.3（draft -18）。
现在已经是 2018.05，相信目前 Wireshark 的最新版本支持的 TLS 1.3 草案版本应该越来越高。
在这篇文章中，我最终使用的 Wireshark 版本是 2.6 版本，服务器和浏览器测试的 TLS 1.3 版本是 draft -23。
如何让服务器和浏览器支持 TLS 1.3，参考我以前的博文《让Nginx快速支持TLS1.3协议》。
总结一点，如果想分析 TLS 1.3 版本，请下载最新的 Wireshark 版本（目前最新的是 2.6 版本）。
WSSLKEYLOGFILE
现在思考一个问题，类似于 Wireshark 这样的流量分析工具，为了分析首先要捕获 TLS 流量，考虑到 TLS 流量是加密的，Wireshark 是如何解密这些流量的呢？
为了解密流量，通常有两种方法：
· 在 Wireshark 中配置服务器的私钥，该私钥和证书中包含的公钥是一对密钥。
· 通过 WSSLKEYLOGFILE 方式。
使用第一种方法解密 TLS 流量的原因很简单，但有局限性。对于 RSA 密钥协商算法，通过私钥 Wireshark 能够解密会话密钥（Master Secret），从而能够解密 TLS 流量；而对于 DH 密钥协商算法（支持前向安全的密码套件），服务器的私钥并不是用于协商会话密钥的，而就是说会话密钥由客户端和服务器内部运算出来的，通过分析纯粹的 TLS 流量，Wireshark 是无法获取获取会话密钥的，从而也就无法解密 TLS 流量。
而第二种方法能够比较完美的解密 TLS 流量，WSSLKEYLOGFILE 是 Mozilla 的 NSS 底层密码库提出的一种技术，所有基于 NSS 的应用程序在运行期间可以将通信过程中的会话密钥导出到一个文件中，一旦有了这个密码文件，Wireshark 就能够解密所有的 TLS 流量了。
现在 OpenSSL 等其他的 TLS 实现也能支持这种方式，通过 Chrome 和 Firefox 浏览器捕获 TLS 流量，Wireshark 就能够解密了。
那么如何配置 WSSLKEYLOGFILE 呢？主要包含两个步骤：
· 设置环境变量 WSSLKEYLOGFILE（在 Windows 中设置非常简单），定义一个文件目录（Chrome 和 Firefox 浏览器就是将会话密钥导入到这个文件中），比如文件是 c:\ssl.log。
· 在 Wireshark 中打开【编辑】-【首选项】-【Protocols】->【SSL】，然后设置 【Pre-Master-Secret log filename】，具体见下图。
wireshark_2.png
<center>图2：Wireshark 设置 WSSLKEYLOGFILE</center>
需要注意的是，配置完成后，需要重启浏览器和 Wireshark，然后就能够成功解密 TLS 流量了。
那么配置 WSSLKEYLOGFILE 变量，Wireshark 在分析的时候有什么具体的差异呢？下面两张图能够说明：
wireshark_3.png
<center>图3：成功解析 HTTP 流量</center>
通过上图可以看出，Wireshark 最终能够解密 HTTP 协议的内容。
wireshark_4.png
<center>图4：无法成功解析 HTTP 流量</center>
通过上图可以看出，Wireshark 无法解密 HTTP 协议的内容，因为没有配置 WSSLKEYLOGFILE，Wireshark 无法获取会话密钥。
上面两张图都是基于 TLS 1.2 协议进行分析的（对于 TLS 1.3 同样适用），需要特别说明的是，对于大部分人来说，主要使用 Wirehark 分析 TLS 协议的握手过程，可能并不关注应用层（比如 HTTP）消息。
· 对于 TLS 1.2 协议流量，如果不关心应用层消息，不配置 WSSLKEYLOGFILE 也能了解握手过程。
· 对于 TLS 1.3 协议流量，由于 server hello 之后的消息都是加密的，如果不配置 WSSLKEYLOGFILE，那么完整的握手过程将无法解密。
总结，如果你想分析 TLS 1.3 协议，你必须配置 WSSLKEYLOGFILE。
如果你对浏览器导出的会话密钥文件感兴趣，可以参考NSS Key Log Format。
会话密钥文件格式很简单：
<Label> <space> <ClientRandom> <space> <Secret>
· Label 表示标签，如果是 TLS 1.2 以下的协议，则该值为 CLIENT_RANDOM；而针对 TLS 1.3 协议，label 对应的值有很多，具体可以参考文档。
· ClientRandom 表示客户端 hello 消息发送的随机数。
· Secret 表示客户端和服务器端协商出的会话密钥。
使用 Wireshark 分析 TLS 1.3
一旦使用 Wireshark 2.6 配置了 WSSLKEYLOGFILE，那么就能完整的分析 TLS 1.3 流量了，具体可以看下图：
wireshark_5.png
<center>图5：Wireshark 2.6 分析 TLS 1.3</center>
从该图可以看出，服务器 server hello 消息最终协商的版本是 TLS 1.3（draft 23），至于 server hello 发送的 Version 变量是 TLS 1.2，就权当是 Wireskarh 的一个 Bug。
通过上图可以看出 TLS 1.3 版本和 TLS 1.2 版本是不同的，比如多了 Encrypted Extension 消息，当然还包括其他的消息。
如果没有配置 WSSLKEYLOGFILE，可能就会出现下列图描述的内容：
wireshark_6.png
<center>图6：Wireshark 2.6 分析 TLS 1.3（没有配置 WSSLKEYLOGFILE）</center>
可见，Server hello 后的消息（主要是众多握手子消息），Wireshark 根本无法分析。
希望通过这篇文章，开启你的 TLS 1.3 协议分析之路，因为 Wireshark 确实是一个好工具。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
