![TLS 中的疯狂完成消息](https://linux22.com/image/1408323/TLS%20%E4%B8%AD%E7%9A%84%E7%96%AF%E7%8B%82%E5%AE%8C%E6%88%90%E6%B6%88%E6%81%AF.png)
我试图理解 TLS 的内容Finished Message
。我使用 wireshark 捕获浏览器和互联网之间的流量。当选择的密码套件为 AES_GCM 时,我注意到了“奇怪之处”。将其设置为流密码,它不会进行哈希处理。如果我理解正确,则在完成消息中发送的数据是:
- 8 字节显式随机数
- 12字节verify_data
- 16字节认证标签
那是,36 字节总共。“问题”在于,Finished Message 数据包大小为40 字节。
下面是:
消息包为什么是40字节,红色字节是什么?
为什么 wireshark 会看到两个 hello 请求?
还有这个...客户回答说176 字节包:
我要疯了……
我错过了什么?
答案1
编辑:最初我以为消息已被损坏,但 dave_thompson 的评论是正确的,并且完成的消息是用 GCM 加密的(我最初假设是 CBC),因此根据这个新信息答案是固定的。
查看服务器的二进制内容,14 03 03 00 01 01 是更改密码规范消息,后面跟着以下字节(以及我对它们含义的解释):
16(握手记录头)
03 03(TLS 版本 1.2)
00 28(消息长度)
00 00 ...[40 字节](加密消息)
Dave 在下面的评论中正确地描述了加密的 AES GCM 结构。但是,根据 Wireshark 的分析,Wireshark 似乎无法理解接下来是加密消息(在 Change Cipher Spec 之后),因此它尝试将其解析为未加密的握手消息。前导 0x00 表示消息类型为 Hello Request,后面的数据与此并不矛盾,因此 Wireshark 错误地将其解析为未加密的 Hello Request,而不是加密的 Finished 消息。
关于 36 字节与 40 字节,完成的消息是 16 字节:
1 字节标头(0x14 表示完成)
3 字节长度(0x00000c 表示 12 字节)
12 字节数据
这额外的 4 个字节(完成消息的标题和长度)解释了差异。
对于接下来的 176 字节客户端消息,176 字节是加密记录长度。如果不解密,我无法知道其中的内容,但它以 0x16 开头,这表示握手,因此它可能是客户端完成消息以及一个或多个其他握手消息。
答案2
#为什么是40字节?
消息包为什么是40字节,红色字节是什么?
我不知道。“更改密码规范”之后的所有内容都是加密的。
来自https://www.rfc-editor.org/rfc/rfc5246#section-7.1:
The ChangeCipherSpec message is sent [...]
before the verifying Finished message is sent.
[...] once the ChangeCipherSpec has been sent, the
new CipherSpec MUST be used.
从https://www.rfc-editor.org/rfc/rfc5246#section-7.4.9:
The Finished message is the first one protected with
the just negotiated algorithms, keys, and secrets.
#为什么是两个?
为什么 wireshark 会看到两个 hello 请求?
我猜它在尝试解释加密数据时感到困惑。
建议
- 尝试再次捕获,但这次让 Firefox 记录预主密钥。然后使用预主密钥通过 WireShark 解密。请参阅:SecSE 问题