-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
-
Workaround Exists
-
-
Undefined
If a GET or POST with no body is sent via HTTPS with an Expect: 100-continue header, then it is silently closed with no response. Tracing clarifies this is from HttpServerConnection.terminateRequestChannel so relates to the CVE-2020-10705 fix:
TRACE [io.undertow.request.io] (default task-3) Exception closing read side of SSL channel: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1542)
at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:628)
at io.undertow.protocols.ssl.SslConduit.terminateReads(SslConduit.java:219)
at org.xnio.conduits.AbstractSourceConduit.terminateReads(AbstractSourceConduit.java:42)
at org.xnio.conduits.AbstractSourceConduit.terminateReads(AbstractSourceConduit.java:42)
at org.xnio.conduits.ConduitStreamSourceChannel.close(ConduitStreamSourceChannel.java:168)
at org.xnio.IoUtils.safeClose(IoUtils.java:152)
at io.undertow.server.protocol.http.HttpServerConnection.terminateRequestChannel(HttpServerConnection.java:149)
A plain HTTP connection still gives a response.
- clones
-
JBEAP-20398 [GSS](7.3.z) UNDERTOW-1816 - HTTPS connection abruptly closed by HttpServerConnection
- Closed