TLS 中的疯狂完成消息

Question 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 开头，这表示握手，因此它可能是客户端完成消息以及一个或多个其他握手消息。

Answer

编辑：最初我以为消息已被损坏，但 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 开头，这表示握手，因此它可能是客户端完成消息以及一个或多个其他握手消息。

Question 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 问题

Answer