Created attachment 37544 [details] Patch that utilizes strtoull to validate Content-Length Too small Content-Length validation breaks SSTP We believe a recently added Content-Length check has started breaking SSTP connections. Tunneling SSTP though httpd would work for us in httpd 2.4.39 but with httpd 2.4.46 we see the following error in the logs: [core:debug] protocol.c(1395): AH10242: client sent invalid Content-Length (18446744073709551615): /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ The SSTP spec (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/7e5b2134-b4bf-435a-85bf-bfe0313fd889) specifies that a Content-Length of 18446744073709551615 (ULONGLONG_MAX) must be set on all SSTP connections. Commit 2efe92b51dc4c33c907c9b8c17cb5038aad8038c "core, protocol: reject invalid Content-Length ASAP." (https://github.com/apache/httpd/commit/2efe92b51dc4c33c907c9b8c17cb5038aad8038c) has added a Content-Length check that (inadvertently?) restricts the Content-Length to a signed long. The commit calls ap_parse_strict_length that ultimately calls strtol to verify the input. This will give an ERANGE error on ULONGLONG_MAX and thus prematurely end the connection. A possible patch (that replaces strtol to strtoull) is attached. I should probably confess that we're using apache httpd as a reverse proxy for sstp with a custom written mod_proxy_sstp. Unfortunately the content-length check happens before mod_proxy_sstp gets called and so our mod is never called anymore. We would be very grateful if the Content-Length check could be made more lenient again so it will support protocols such as SSTP once more. kind regards Karsten
"specifies that a Content-Length of 18446744073709551615 (ULONGLONG_MAX)" What could possibly go wrong? IMO, this is obviously deliberately invalid (and unsafe) use of HTTP, and httpd is correct to reject it. The protocol should chunked bodies if you need to avoid specifying a C-L. I'd suggest writing a lower level filter to handle this not-really-HTTP protocol.
In our defense: - Strictly speaking RFC 2616 section 14.13 does allow ULONGLONG_MAX as a content-length. - Version 3.4.39 did support it. - The commit that broke it only says it wants to check for validation errors sooner in the code, not stricter. We therefore figured it was accidental that existing applications got broken.
A little bit of a background: RFC 7230 which supersedes RFC 2616 defines no maximum number that can be specified in the content-length field (3.3.2), but in 9.3. it recommends to reject too large payloads (RFC 7231, 6.5.11) in order to avoid attacks. The clength field in the request_rec struct has been of type long / apr_off_t for about 20 years. Hence it is sensible for httpd to reject larger content lengthes. The type of the field could be changed, but not for stable versions. Hence this is not an option for 2.4.x.