【问题标题】：SSL_ERROR_RX_RECORD_TOO_LONG with custom serverSSL_ERROR_RX_RECORD_TOO_LONG 与自定义服务器
【发布时间】：2019-12-31 22:18:40
【问题描述】：

我创建了一个基于套接字的web server。它可以通过 HTTPS 或 HTTP 提供文件。

我遇到的问题是在使用 Firefox 和 Chromium 通过 HTTPS 从服务器请求文件（例如图像）时发生的。

当 Firefox 从https://localhost:8443/ada.jpg 的服务器请求图像时，Firefox 会报告

SSL_ERROR_RX_RECORD_TOO_LONG

同样，Chromium 错误与

ERR_SSL_PROTOCOL_ERROR

以下工作正常：

cURL 通过 HTTPS 获取图像：curl -Ok "https://localhost:8443/ada.jpg"
使用 cURL、Firefox 和 Chromium 通过 HTTPS 获取文本响应：https://localhost:8443/
使用 cURL、Firefox 和 Chromium 通过 HTTPS 获取更小的图像（6773 字节），例如 this one
使用 cURL、Firefox 和 Chromium 通过 HTTP（无 TLS）获取图像：http://localhost:8443/ada.jpg

我使用 Wireshark 在浏览器获取图像时查看帧：Firefox 和 Chromium 都会在图像仍在传输时向服务器发送[FIN, ACK] 帧。服务器继续发送部分图像，之后浏览器发送一个[RST] 帧。

这些是 Firefox 和服务器之间交换的最后几帧：

25  1.873102771 ::1 ::1 TCP 86  55444 → 8443 [ACK] Seq=937 Ack=18043 Win=56704 Len=0 TSval=3976879013 TSecr=3976879013
26  1.873237965 ::1 ::1 TLSv1.3 110 Application Data
27  1.873247272 ::1 ::1 TCP 86  8443 → 55444 [ACK] Seq=18043 Ack=961 Win=65536 Len=0 TSval=3976879013 TSecr=3976879013
28  1.873346910 ::1 ::1 TCP 86  55444 → 8443 [FIN, ACK] Seq=961 Ack=18043 Win=65536 Len=0 TSval=3976879013 TSecr=3976879013
29  1.876736432 ::1 ::1 TLSv1.3 16508   Application Data
30  1.876769660 ::1 ::1 TCP 74  55444 → 8443 [RST] Seq=962 Win=0 Len=0

Here 是 Wireshark 捕获的 cURL 和 Firefox。

为了重现错误，请执行

git clone git@gitlab.com:bullbytes/simple_socket_based_server.git
cd simple_socket_based_server
./gradlew run

这将启动启用了 TLS 的服务器。然后，在浏览器中打开以下 URL（第一次您必须为自签名证书添加例外）：

https://localhost:8443/ada.jpg

要说服自己在禁用 TLS 时传输图像成功，请像这样启动服务器：

./gradlew run --args="--use-tls=no"

从协议中删除s 后，图像应该会显示在您的浏览器中：

http://localhost:8443/ada.jpg

服务器的请求处理循环是here。

如何进一步调试并修复它？

我在 Arch Linux 5.2.9 上使用 OpenJDK 12.0.2+10。

【问题讨论】：

您是否已经检查过这个：stackoverflow.com/questions/119336/… ？
是的，我做到了。该问题中描述的问题是 Apache 的错误配置，不符合我的问题中描述的症状，即在某些条件下通过 TLS 传输数据是有效的。

标签： java ssl

【解决方案1】：

这是 JDK 中的一个错误

它已在 JDK 13 中修复¹。

原始错误报告为here，标题为

TLSv1.3 可能生成长于 2^14+1 个字节的 TLSInnerPlainText

这与问题中的观察结果一致：比violates TLSv1.3 协议更长的记录。

This bug report 声明 Java 的 TLS 实现通过this commit 在 JDK 11.0.5 b01 和 13 中得到修复。

通常，JDK 13 reimplementedSocket 和 ServerSocket²，使它们与 project Loom 中引入的纤维配合得很好。

我为 JDK 12 提交的错误是 here。

解决方法

如果在您的情况下无法升级 JDK，您现在可以使用 ServerSocketChannel 而不是 ServerSocket。 Jetty 就是这样做的。

¹_{在 Arch Linux 上的 OpenJDK build 13+33 不会出现该错误：图像在 Firefox 中显示正常}

²_{用于重现错误的The server是建立在ServerSocket之上的。}

【讨论】：