Bug 65368 - enhance error message "Unable to unwrap data, invalid status [CLOSED]"
Summary: enhance error message "Unable to unwrap data, invalid status [CLOSED]"
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Util (show other bugs)
Version: 9.0.37
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-09 08:23 UTC by Ralf Hauser
Modified: 2021-06-15 09:42 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2021-06-09 08:23:06 UTC
on a form post, I am seeing 

Caused by: java.io.IOException: Unable to unwrap data, invalid status [CLOSED]
	at org.apache.tomcat.util.net.SecureNioChannel.read(SecureNioChannel.java:657)
	at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1231)
	at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1158)
	at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:736)
	at org.apache.coyote.http11.Http11InputBuffer.access$300(Http11InputBuffer.java:42)
	at org.apache.coyote.http11.Http11InputBuffer$SocketInputBuffer.doRead(Http11InputBuffer.java:1099)
	at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:102)
	at org.apache.coyote.http11.Http11InputBuffer.doRead(Http11InputBuffer.java:247)
	at org.apache.coyote.Request.doRead(Request.java:551)
	at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336)


It turns out that post body was empty, i.e. of 0 bytes length.
So it is probably not really a decryption problem, but simply no data received.

Please add the number of bytes "read" (0 in my case) and "netread" (53 in my case) to the error message on line 657 to ease the search of the cause (which in my case was rather on the client side)
Comment 1 Mark Thomas 2021-06-09 17:47:40 UTC
Reading a zero length POST shouldn't trigger an exception. I'll see if I can re-create this. Was this with OpenSSL or JSSE?
Comment 2 Mark Thomas 2021-06-09 18:26:34 UTC
I'm unable to repeat this with a simple test servlet and zero length POST. I'm using openssl s_client.

The stack trace suggests the connection has been closed so this may not be (directly) related to the length of the POST.

Can you provide a simple test case to reproduce this please.
Comment 3 Mark Thomas 2021-06-10 08:10:49 UTC
Thanks for the additional information provided off-line.

I used chrome with SSLKEYLOGFILE and Wireshark to look at a test request to the server you provided details of.

The Wireshark trace shows the client submitting the POST request and then immediately closing the TCP connection. This is consistent with what is reported in the stack trace - that the connection has been closed.

This looks like a broken client to me.

Generally, clients closing the connection should be silently ignored by Tomcat. We typically log such events as debug level for instances such as this where there is a client error that needs to be debugged.

I do want to see if I can recreate this locally with a simple test case as we may need to adjust the logging in this scenario.
Comment 4 Mark Thomas 2021-06-10 09:14:32 UTC
I can recreate this. It is caused when the client closes the connection cleanly when Tomcat expects the connection to remain open. Tomcat reads the TLS close message which gets handled in the "Something else went wrong block".

The current message doesn't really reflect what is going on. I think returning -1 which will trigger an EOFException in the caller is a better, more consistent way to handle this. It also clearly signals what went wrong - Tomcat found a closed connection when it tried to do a read.
Comment 5 Mark Thomas 2021-06-15 09:42:19 UTC
After further review fixed slightly differently to allow for TLS 1.3 half-close.

Fixed in:
- 10.1.x for 10.1.0-M2 onwards
- 10.0.x for 10.0.8 onwards
- 9.0.x for 9.0.49 onwards
- 8.5.x for 8.5.69 onwards