I think we should *always* close connections in cases where it can lead to request smuggling vulnerabilities like when there is an error during header or request line parsing, but allowing the user to control connection close when the status is being set by the user, should be safe?
It allows users to send back responses like InvalidInputException with a 400 status without being forced to close the connection. On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat <r...@apache.org> wrote: > On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas <ma...@apache.org> wrote: > > > > On 18/04/2024 09:07, Stefan Ansing wrote: > > > Hi, > > > > > > We've observed some unexpected behaviour in Apache Tomcat (version > 10.1.19) > > > where we see that HTTP/1.1 connections are closed whenever a servlet > > > application returns the following status codes: 400, 408, 411, 414, > 500, > > > 503, 501. This causes client applications to rapidly reconnect and > induce > > > high server-side CPU load due to doing TLS handshakes. > > > > > > The 400 and 500 status codes are commonly used in RESTful > microservices to > > > communicate errors. Reviewing RFC 9112 I couldn't find any requirement > for > > > closing connections on these status codes. > > > > > > After testing with Undertow (version 2.3.12), where we didn't see the > same > > > behaviour, we believe that these status codes do not necessitate a new > > > connection. > > > > The Tomcat developers disagree. Connections are closed after these > > status codes to avoid various forms of request smuggling attacks. > > > > > Checking the Tomcat sources makes me believe that the behaviour is > > > hard-coded[1]. I'm reaching out here to re-evaluate the list of status > > > codes and to discuss the possibilities of making the behaviour > configurable. > > > > Making this list of status codes configurable seems reasonable. The > > default can stay as current and if users want to change it then they > > have to accept the associated security risks. > > If it's insecure, then it would still be a valid CVE even if the > configuration is optional. We don't have an "allowSmuggling" attribute > on the connector to relax header or status line parsing, even though > many would have wanted it in the past ... > > Rémy > > > Mark > > > > > > > > > > A colleague of mine reported a bug for this issue: > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=68901 > > > > > > Kind regards, > > > Stefan Ansing > > > > > > [1]: > > > > https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617 > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
