You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2020/07/17 01:28:17 UTC
[Bug 64609] New: Tomcat Error parsing encrypted HTTP request header
https://bz.apache.org/bugzilla/show_bug.cgi?id=64609
Bug ID: 64609
Summary: Tomcat Error parsing encrypted HTTP request header
Product: Tomcat 9
Version: 9.0.37
Hardware: Other
OS: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: jeff_zhuk@yahoo.com
Target Milestone: -----
There are two types of errors that start with "Error parsing HTTP request
header"
1) Invalid character found in the HTTP protocol
2) Invalid character found in method name.
Providing a record of the Http Request Error, Tomcat does not send any response
back to the client.
The socked is not closed and one more Open File added to LFOS (log for open
files).
Eventually number of open files is increased to the limit and Tomcat stops
responding at all.
This situation is covered for regular HTTP request but not for encrypted HTTPS
requests. I am using HTTPS via AWS Cloud Front, worked with AWS support team,
but we could not find a solution. AWS support sincerely tried to help me but
unfortunately failed.
I tried recommended configurations in server.xml and catalina.properties (see
below).
I also tried almost all Tomcat 8.5 versions and the latest Tomcat 9.0.37.
I established ServletFilter class, but it does not help because the error
happens before the filter, in the Tomcat layer. Tomcat has some provisioning
for accepting different character coding in HTTP, but not in HTTPS/encrypted
request.
I highly appreciate anyone who can help here.
Thank you,
Jeff
This is the extract from the standard server.xml
<Connector port="80" maxHttpHeaderSize="16000" protocol="HTTP/1.1"
URIEncoding="UTF-8" connectionTimeout="20000" redirectPort="443"/>
This is the additional two lines in the standard catalina.properties:
# Allow for changes to HTTP request validation
# WARNING: Using this option may expose the server to CVE-2016-6816
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64609] Tomcat Error parsing encrypted HTTP request header
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64609
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
(In reply to Jeff Zhuk from comment #0)
<snip/>
> Providing a record of the Http Request Error, Tomcat does not send any
> response back to the client.
Incorrect.
Where Tomcat has enough information to confirm that the client understands
HTTP, Tomcat will return a response.
An invalid method with an valid URI and protocol will return a 4xx response as
appropriate.
> The socked is not closed
Incorrect. Tomcat closes the connection as confirmed by Wireshark.
> and one more Open File added to LFOS (log for open files).
Also incorrect and confirmed with local testing.
> Eventually number of open files is increased to the limit and Tomcat stops
> responding at all.
> This situation is covered for regular HTTP request but not for encrypted
> HTTPS requests. I am using HTTPS via AWS Cloud Front, worked with AWS
> support team, but we could not find a solution. AWS support sincerely tried
> to help me but unfortunately failed.
> I tried recommended configurations in server.xml and catalina.properties
> (see below).
> I also tried almost all Tomcat 8.5 versions and the latest Tomcat 9.0.37.
>
> I established ServletFilter class, but it does not help because the error
> happens before the filter, in the Tomcat layer. Tomcat has some provisioning
> for accepting different character coding in HTTP, but not in HTTPS/encrypted
> request.
> I highly appreciate anyone who can help here.
Bugzilla is not a support forum. Please use the Apache Tomcat user mailing
list.
Given that the issue is not observed when using Tomcat directly but you do
observe an issue when using AWS that does suggest that the root cause lies
somewhere in AWS.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64609] Tomcat Error parsing encrypted HTTP request header
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64609
--- Comment #2 from Jeff Zhuk <je...@yahoo.com> ---
Mark,
Thank you for looking into the problem.
> An invalid method with an valid URI and protocol will return a 4xx response as appropriate.
Invalid characters make invalid URI and invalidate the protocol. Tomcat does
not provide a response with the Error number, like 500, just throws the
Exception below.
16-Jul-2020 06:31:52.793 INFO [http-nio-80-exec-167]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header
Note: further occurrences of HTTP request parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method
name [0x050x01...]. HTTP method names must be tokens
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:432)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:502)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1626)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
----
16-Jul-2020 18:06:51.220 INFO [http-nio-80-exec-9]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header Note: further occurrences of HTTP request
parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target
[/index.php?s=/Index/\x5Cthink\x5Capp/invokefunction&function=call_user_func_array&vars[0]=sha1&vars[1][]=xyzt].
The valid characters are defined in RFC 7230 and RFC 3986
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:491)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
These exceptions are rare, strange client requests throw the exceptions that
are not caught, handshake with the client is not happening, causing LSOF
growing with the CLOSE_WAIT records:
http-nio- 8774 10605 root 149u IPv6 15950578
0t0 TCP
ip-172-31-42-229.us-west-2.compute.internal:http->64.252.86.223:23914
(CLOSE_WAIT)
http-nio- 8774 10605 root 150u IPv6 15950579
0t0 TCP
ip-172-31-42-229.us-west-2.compute.internal:http->64.252.86.223:25842
(CLOSE_WAIT)
http-nio- 8774 10605 root 151u IPv6 15951160
0t0 TCP
ip-172-31-42-229.us-west-2.compute.internal:http->64.252.86.223:30832
(CLOSE_WAIT)
http-nio- 8774 10605 root 152u IPv6 15950580
0t0 TCP
ip-172-31-42-229.us-west-2.compute.internal:http->64.252.86.35:12450
(CLOSE_WAIT)
See more in http://javaschool.com/lsof.txt
This is my conclusion, which is confirmed by AWS team.
Another possibility is that there is a response to these cases like you said,
but it is so specific, that AWS does not provide it back to the client.
(AWS disregarded this possibility)
If you know the specific response provided by Tomcat, please let me know and I
can work more with AWS layer.
Thank you again,
Jeff
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org