使用tcpdump仅捕获ssl握手

我有一个服务器，许多客户端使用SSL连接到该服务器。最近，我在服务器日志中观察到SSL握手错误（例如SSL MAC错误）。错误本身并不重要，但我想了解为什么有些客户机能够连接，而另一些客户机出现故障，并且还需要确定哪些客户机出现故障

---

为了调试这个问题，我想捕获服务器上发生的所有SSL握手，因为我不知道有问题的客户端何时连接，所以我不想捕获所有通信量，直到发生这种情况。我只想捕获所有SSL握手，然后用Wireshark进行分析。假设我只能访问tcpdump，没有其他用于捕获的工具。

我不知道您到底在调用握手，但我建议使用此命令，它可能会捕获您所需的95%以上的内容：

tcpdump -ni eth0 "tcp port 443 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)"

现在它做什么：

• eth0：是我的网络接口，如果需要，请更改它
• tcp端口443：我想这是服务器正在侦听的端口，如果需要，请更改它
• tcp[（（tcp[12]&0xf0）>>2）]=0x16：有点棘手，让我们在下面详细介绍一下

tcp[12]

意味着捕获tcp数据包的第13个字节，对应于前半部分是偏移量，后半部分是保留的。 偏移量乘以4后给出TCP头的字节计数，这意味着

（（TCP[12]&0xf0）>>2）

提供TCP头的大小

TLS数据包的第一个字节定义内容类型。值22（十六进制中的0x16）被定义为“握手”内容

因此，

tcp[（（tcp[12]&0xf0）>>2）]=0x16

捕获tcp报头后第一个字节设置为

0x16

的每个数据包

---

可以执行更多的过滤，但这严格地回答了您的问题。

我认为公认的答案是一个带有脆弱解决方案的过早优化

SSL握手在建立连接时立即发生

简单方法：在客户端连接到远程主机之前开始捕获，并捕获第一个完整的N个数据包

例如，对于300个数据包：

/usr/sbin/tcpdump-i eth0-p-s 65535-c300“tcp和主机1.2.3.4和端口443”

通过这种方式，wireshark拥有SSL握手的全部有效负载，可以对其进行解码并显示所有位。

如果您还想抓取，则还需要查看+8

tcp[((tcp[12] & 0xf0) >> 2)] = 0x16  or (tcp port 1433 and tcp[((tcp[12] & 0xf0) >> 2) + 8] = 0x16)

---

您可以提到tcpdump中用于捕获的SSL端口不是吗？@Prabhu是的，但它将捕获该端口的所有数据。我只想捕获数据，直到每个请求的SSL/TLS握手完成。所谓握手，我指的是在SSL连接建立期间使用的数据包。这些数据包对应于“ClientHello”、“ServerHello”、“Certificate”等，直到通信的“ApplicationData”部分。是的，它仅在握手期间捕获数据包。但当我在Wireshark中打开生成的文件时，它只显示TCP数据包，无法完全重建SSL消息（例如ClientHello）。这可能是因为此筛选器正在删除某些数据包吗？可能是的。在我的测试过程中，Wireshark会自动将数据包解码为TLSv1.2，但如果您在TCP级别截断了数据包，则无法重建完整的握手。我猜你不能只用tcpdump解决这个问题。如果上面的过滤器不匹配任何数据包，那么你可能处于vlan环境中。将“（tcp[（（tcp[12]&0xf0）>>2）]=0x16”扩展到“vlan和（tcp…”以在该环境中捕获。我遇到了同样的问题，wireshark无法将tcp流量解释为TLS/SSL。我遵循了建议[解决此问题，因为我在非标准SSL端口上捕获流量。