Question

我已经使用SslHandler创建了服务器（10.32.240.50）。客户端（10.32.240.5）连接到服务器，一切正常。一段时间后，客户端会毫无理由地拒绝。我进行了tcp dump，并在断开连接之前看到了加密警报：

我不知道是什么客户端在此警报中向我发送的邮件-已加密。此警报可能是什么原因，以及为什么导致断开连接？有什么办法可以追踪到这些事件？

Answer 1

在此阶段，很难确定您的问题是否确实与编程有关，因此在这里是否为题。

TLS 1.2警报可能有很多事情，请参见https://tools.ietf.org/html/rfc5246#section-7.2，该列表为您提供了整个列表：

  enum { warning(1), fatal(2), (255) } AlertLevel;

  enum {
      close_notify(0),
      unexpected_message(10),
      bad_record_mac(20),
      decryption_failed_RESERVED(21),
      record_overflow(22),
      decompression_failure(30),
      handshake_failure(40),
      no_certificate_RESERVED(41),
      bad_certificate(42),
      unsupported_certificate(43),
      certificate_revoked(44),
      certificate_expired(45),
      certificate_unknown(46),
      illegal_parameter(47),
      unknown_ca(48),
      access_denied(49),
      decode_error(50),
      decrypt_error(51),
      export_restriction_RESERVED(60),
      protocol_version(70),
      insufficient_security(71),
      internal_error(80),
      user_canceled(90),
      no_renegotiation(100),
      unsupported_extension(110),
      (255)
  } AlertDescription;

  struct {
      AlertLevel level;
      AlertDescription description;
  } Alert;

当然，它是加密的，因此，如果您真的想查看它，则需要：

更改客户端，以便在执行触发此错误的连接时输出主密钥和客户端随机
记录与wireshark的相关连接
然后您将能够在Wireshark中使用第一点的项目对其进行解密（您可以找到许多有关该操作的教程）

根据经验，如果警报在某些应用程序数据之后发生，则最可能的情况是“ close_notify”。这是一种“正常”情况，仅表示服务器决定关闭TLS套接字（但不一定是TCP套接字），并因此就此警告（警告）另一方。

如果是这种情况，则期望另一方发送相同的警报，然后使用FIN在TCP级别关闭连接。因此，您所拥有的观察链是可以预期的。剩下的唯一原因是关于初始警报。

澄清后，由于第一个警报来自客户端.5，而不是服务器，这意味着您无法控制的客户端已决定关闭TLS流，原因仅出于此原因（如果我们仍然正确地认为警报是“ close_notify”，则仅当您按照上述说明解密交换，或者增加服务器的详细程度时才能测试该猜测，例如@ dave_thompson_085在注释中给出的想法： “如果设置sysprop javax.net.debug = ssl，它将跟踪所有JSSE（SSL / TLS）操作，其中包括收到的警报。”）

除此之外，除了询问客户操作员/开发人员外，我看不到任何原因可以理解为什么客户决定不再与您交谈。这还取决于交换的基础应用程序数据，也许确实是传输的结束，并且客户端不再需要TLS流了？

如何在Netty中处理SSL加密警报

1 个答案: