1

我们有一个通过 TLS 进行通信的客户端/服务器架构。我们有 Java、Linux 和 Windows 客户端，并使用SSLSocketJava、Linux 上的 OpenSSL 和基于 SSPI 的 Windows 实现。不幸的是，我没有找到太多关于 Windows 10 的信息（除了可以启用 TLS 1.3 并且不应该在生产中使用）。

在测试我们的更改以支持 TLS 1.3 时，当一侧是 Windows 而另一侧是 Java 或 OpenSSL 实现时，当 Java 触发密钥更新（或者我们在 OpenSSL 中手动触发密钥更新）时，我看到以下问题：

Java调试：

javax.net.ssl|ALL|01|main|2020-07-16 18:28:53.269 CEST|SSLSocketImpl.java:1209|trigger key update
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.271 CEST|KeyUpdate.java:271|Produced KeyUpdate post-handshake message (
"KeyUpdate": {
  "request_update": update_requested
}
)
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.271 CEST|SSLCipher.java:2020|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 1048576
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.271 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 5
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.271 CEST|SSLCipher.java:2062|Plaintext before ENCRYPTION (
  0000: 18 00 00 01 01 16 00 00   00 00 00 00 00 00 00 00  ................
  0010: 00 00 00 00 00 00                                  ......
)
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.272 CEST|SSLSocketOutputRecord.java:255|Raw write (
  0000: 17 03 03 00 26 49 4C 9F   D7 1F D1 26 8E 32 B7 7F  ....&IL....&.2..
  0010: 5F 8F E2 71 D1 AF 43 D9   E9 06 56 CF 86 71 2A DC  _..q..C...V..q*.
  0020: BF 44 A1 12 83 AC D3 92   EB B1 B7                 .D.........
)
javax.net.ssl|DEBUG|01|main|2020-07-16 18:28:53.272 CEST|KeyUpdate.java:323|KeyUpdate: write key updated

数据到达 Windows 端并放入DecryptMessage. 它返回SEC_E_INVALID_TOKEN，但缓冲区更改为

16 03 03 00 26   18 00 00 01 01 16 00 00   00 00 00 00 00 00 00 00  00 00 00 00 00 00

这实际上是Java端发送的以握手记录头（0x16）为前缀的解密数据。

我的问题是：这是限制之一，尚未在 Windows 中完全实现吗？或者这应该已经起作用并且我做错了什么？在这种情况下，我希望 SEC_I_RENEGOTIATION 返回代码，并且我必须将解密的数据放入InitializeSecurityContextor AcceptSecurityContext。

我在 Windows 10 版本 2004（操作系统版本 19041.330）上对此进行了测试。

问候， 安德烈亚斯

4

0 回答 0