我们与某些第 3 方 https 端点的连接存在问题。我们通过 Wireshark 检查了网络包以找到问题，但我们还没有发现任何问题。
我比较了一个工作端点和一个不工作端点以查看差异并看到 Wireshark 上显示的一种奇怪类型的协议。
Wireshark 在数据包列表中将 ClientHello 显示为 SSL。但是，如果我检查包的 SSL 层，我会将其视为版本：TLS 1.2 (0x0303)
为什么 Wireshark 将此数据包识别为 SSL？
这是捕获的包 .pcapng 文件：
错误的协议：（连接从服务器端重置） https://drive.google.com/open?id=0B95MNyFyqGw0bFk2ZFhMdEFpRDQ
正确的协议：（连接正常） https://drive.google.com/open?id=0B95MNyFyqGw0OVVVd3VIa19Ud3M
我们怀疑这个错误的协议可能导致连接失败。
Wireshark 根据几个变量识别协议。在这种情况下，它开始假设 SSL，然后在其分解过程中对其进行更改。
我注意到好的捕获包含一个握手会话 ID，而坏的则没有。我认为这是错误捕获停留在 SSL 的原因之一。
无论如何，很明显这是两个不同的客户端版本，这就是您要重置的原因。您可以尝试在 PA 上允许较旧的 SSL 版本，看看是否有帮助。
这是Wireshark wiki 上类似问题的链接。
不久前在 Reddit 上提出了这个问题。
这是我的答案：
SSL 是 Netscape 1994 年开发的原始协议。这是 SSL 版本 1.0（主要版本
1次要版本0）。1995 年，Netscape 推出了 SSL 2.0 版（主要版本2次要版本0）。1996 年，Netscape 推出了 SSL 3.0 版（主要版本3次要版本0）。1999 年，“SSL”协议的维护工作交给了 IETF，后者将其更名为“TLS”。他们从 TLS 1.0 开始，这是 主要版本
3次要版本1。它继续...... TLS 1.1 是主要版本
3次要版本2。TLS 1.2 是主要版本3次要版本3如您所见，TLS（一直到 1.2）主要是对 SSL 3.0 的次要修订。实际上，您看到的是 SSL3.0 结构化标头，广告客户端可以支持最高版本 3、次要版本 3 的 SSL，也就是俗称的 TLS1.2。
因此，Wireshark 将其解码为 SSLv3.0 标头——自 SSL3.0 以来标头格式没有改变。而 SSL2.0 是一个全新的标头，如果您可以强制浏览器启动 SSL2.0 握手，您会看到 Wireshark 对其进行解码。（虽然谷歌出现了这个）
我找不到一个完美的参考来证明这一点，但你可以在 TLS1.2 RFC 的附录 E 中找出它的要点。
较新版本的 Wireshark 会将协议标签更正为在 Client Hello 和 Server Hello 消息之后两个客户端之间协商的内容。
如果您从捕获中删除 Server Hello，您将看到 Wireshark 将继续将整个对话标记为“SSL 3.0”，因为它不知道同意的 SSL/TLS 版本是什么。
有关参考，请参阅 TLS/SSL 握手。
两个客户端 hello 都具有相同的内容 TLSv1.2，标签的不同来自于在第一个实例中协商没有完成，因此wireshark 对两个数据包进行不同的标签。在 pcap 文件中，您可以看到客户端尝试建立 SSL 连接后，服务器使用 RST、ACK 数据包重播。尝试建立另一个连接的客户端再次被标记为 TLSv1.2。但服务器再次发送 RST。两者都是 TLSv1.2，wireshark 标记它们的方式不同。我会假设服务器配置错误。我建议检查服务器上使用的密码套装。
解决此问题的最佳方法可能是简单地尝试使用 openssl 连接到服务器。
openssl s_client -connect example.com:443
您应该看到在此事务中选择了什么密码（如果它完全有效）。
但是这篇文章对于这个小组来说是题外话。