应用错误收集

Java 11的发布具有TLSv1.3支持，默认情况下使用。

在HTTPS和SSL套接字的上下文中它可以正常工作，但是似乎在使用SSLEngine时，由于TLSv1.3行为的变化，还存在其他障碍。

因此，使用NIO可以通过SSLEngine进行可靠的通信实现，而启用TLSv1.3时将不再起作用。没有明显的错误，以异常或SSL错误的形式出现，两个节点将只是来回发送包装消息/包装消息，并最终超时。

我对使用TLSv1.2的SSLEngine和使用TLSv1.3的SSLEngine之间的行为更改的确切列表以及可能的情况之间的迁移清单感兴趣。不幸的是，Java 11的SSLEngine javadocs没有此信息-Java 11中没有新方法，也没有对TLSv1.3的引用。

的确，在JDK 11的Javadoc中没有明确提及TLS 1.3对SSLEngine的影响，并且其方法也没有变化。

然而，the fifth item (closure) in the list of phases of SSLEngine在JDK 11中的Javadoc开头的一般说明中已更新：

关闭-当不再需要连接时，客户端和服务器应用程序应各自关闭各自的两侧连接。对于 SSLEngine 对象，应用程序应调用 closeOutbound() ，然后将剩余的所有消息发送给对等方。同样应用程序应接收来自对等方的所有剩余消息致电 closeInbound() 之前。潜在的运输机制可以然后在 SSLEngine 的两侧都关闭后将其关闭。如果连接未按顺序关闭（例如在同级的写关闭通知之前调用 closeInbound() 已收到），则将引发异常以指示发生错误。引擎一旦关闭，便无法重复使用：必须创建新的 SSLEngine 。

Oracle's Release Notes for JDK 11中还讨论了该更改：

TLS 1.3半封闭政策
  一个新的系统属性，    jdk.tls.acknowledgeCloseNotify ，已添加。的默认值   系统属性为假。如果系统属性设置为true，则   收到相应的 close_notify alert    close_notify 警报，连接将被双工关闭。

TLS 1.2和更早版本使用双工关闭策略，而TLS 1.3   使用半封闭策略。入站和出站close_notify   TLS 1.3的警报是独立的。升级到TLS 1.3时，   如果您的应用程序关闭了   （D）仅使用 SSLEngine.closeInbound() 之一进行TLS连接    SSLEngine.closeOutbound() API，但不能同时使用   连接。如果您的应用程序出现意外的挂起或超时   当基础（D）TLS传输未双工关闭时，您   可能需要将此属性设置为true。

请注意，当不再需要TLS / DTLS连接时，客户端   和服务器应用程序应各自关闭其两侧   各个连接。

因此，将jdk.tls.acknowledgeCloseNotify与TLS 1.3结合使用时，将SSlEngine设置为 true 可能会解决您对超时的特定担忧：

如果在基础（D）TLS传输未关闭的情况下您的应用程序出现意外的挂起或超时 ，则可能需要将此属性设置为true。

发行说明文档还链接到已关闭的JDK错误JDK-8208526 : TLS 1.3 half-close and synchronization issues，该错误将更详细地讨论更改。

相关的（和已关闭的）错误JDK-8207009 : TLS 1.3 half-close and synchronization issues可能也很有趣。

其他参考文献：

请参阅RFC 8446的“ 附录D.向后兼容性”：“ 传输层安全性（TLS）协议版本1.3 ”（第138-141页））。
在此Oracle视频“ Monday Technical Sessions: Moscone West 2004”中，在2:53:37和2:56:35之间简要讨论了TLS 1.3与早期版本之间的兼容性。

最后，我们需要在握手完成后从缓冲区读取剩余数据，将其解包并更新握手状态。看起来像是我们以前没有处理过的边缘情况。

升级到TLSv1.3时SSLEngine使用率的变化

2 个答案: