parsing - 在 TLS 协议(protocol)中解析扩展问候消息的正确方法是什么?

标签 parsing ssl network-programming wireshark

根据 RFC 5246 (它定义了 TLS 协议(protocol)版本 1.2)

第 18 页:

The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).

第 40 页说:

TLS allows extensions to follow the compression_methods field in an extensions block. The presence of extensions can be detected by determining whether there are bytes following the compression_methods at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.

我从这段话中了解到,当我解析完一个ClientHello 消息时,我应该将它的大小与封装记录层的TlsPlaintext.length 字段进行比较message 查看记录层message 末尾是否有多余的字节,如果有,将它们解释为Extension 结构。

这实际上对我测试我的应用程序的一些 TLS 流量样本有效,但对其他一些样本失败(即它无法检测到 wireshark 可以检测到的消息)。当我使用 wireshark 查看有问题的数据包时,它看起来像是几个握手消息组合成一个握手消息。这些是带有扩展的 ServerHello(看起来与 ClientHello 完全一样)、CertificateServerHelloDone 消息。

当 Hello 消息被封装在单个握手消息中时,检测 Hello 扩展很容易,但我不明白当同一个握手消息中存在其他握手消息时,如何在 hello 消息之后检测扩展部分的存在和边界在他们之后留言。

如有任何关于如何解析这些数据包的帮助或建议,我们将不胜感激。

最佳答案

属于(hanshake 协议(protocol)、更改密码规范协议(protocol)、警报协议(protocol)、其他协议(protocol))的每个 TLS 消息都在记录层协议(protocol)内(或之上)发送。看看这个:https://technet.microsoft.com/en-us/library/cc767139.aspx

记录层协议(protocol)将提供:

  • 内容类型(1 个八位字节)
  • 版本(2 个八位字节)
  • 长度(2 个八位字节)

每个 TLS 消息都将以这些字段开头,即使您在同一 TCP 段的有效负载中看到许多 SSL 消息也是如此。您可以将这些消息解析为单独的 TLS 消息。

SSL Record Protocol中的Length会给出上层协议(protocol)报文的总长度。如果它是作为握手协议(protocol)一部分的 Hello 消息,它将包含扩展。该字段还可以让您确定边界或许多 TLS 消息聚集在一起。

在 Hello 消息的情况下,在压缩方法字段之后,您有 2 个八位字节指示扩展长度。扩展包含在包含 Hello 消息的 SSL 记录协议(protocol)的长度字段中。它们也包含在同一 Hello 消息的长度中。

在 SSL 记录层之后,不同协议(protocol)的每条消息都以自己的方式解析:

  • 更改密码规范协议(protocol):始终为 1 个八位字节
  • 握手协议(protocol):TLV(类型、长度、值)
  • 警报协议(protocol):2 个八位字节(级别、警报)
  • HTTP 或其他...

因此,当您有许多 TLS 消息聚集在同一个 TCP 段中时,您总是:

Offset = 0
While more data (based on TCP payload length):
    Read first 5 octets at Offset
        Obtain Length field (Assign to MessageLength, Offset += 5)
            Process first TLS message from Offset, with length MessageLength
            Offset += MessageLength

我希望我正确地解决了你的问题......

关于parsing - 在 TLS 协议(protocol)中解析扩展问候消息的正确方法是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31655414/

相关文章:

objective-c - Gpx 解析器或 GPX 文档

Ruby Mechanize 在身份验证重定向期间崩溃; sslv3 警报非法参数

networking - 有哪些方法/语言用于描述网络协议(protocol)/数据包结构?

c++ - 在 C++ 中将字符串解析为未知数量的正则表达式组

python - 在python中解析PDF形状数据

java - 使用 DOM 和 java 将节点值添加到 xhtml

java - 使用 IP 的有效 Android 证书

android - Android 5.0 及更高版本是否支持 TLS v1.0?

c - 有没有办法在 Linux 中使用 C 以编程方式设置接口(interface) MTU?

Linux版Windows "nonpaged pool"这种东西存在吗?