https://issues.apache.org/bugzilla/show_bug.cgi?id=55422
Bug ID: 55422
Summary: mod_proxy's HTTPS client generates bad requests with
Host != SSL_TLS_SNI
Product: Apache httpd-2
Version: 2.4.6
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy
Assignee: [email protected]
Reporter: [email protected]
When clients access an Apache reverse proxy with differing host names (and thus
different "Host" headers), Apache's HTTPS client can generate improper requests
to the origin server that have Host != SSL_TLS_SNI.
Here's the simplest setup where I could reproduce the problem:
Server A: Let's call it "dmz.example.com", and suppose its IP address is
192.168.1.100. Its Apache has one HTTPS VirtualHost. ProxyPreserveHost is on,
and there is one ProxyPass to the origin server, i.e.:
ProxyPreserveHost on
ProxyPass /foo https://192.168.1.200/foo
Server B: Call this one "origin.example.com", and suppose its IP address is
192.168.1.200. Its Apache has one HTTPS VirtualHost and it's just serving up
HTML files.
Fire up both Apache servers, then repeatedly do this from a bash shell:
curl https://dmz.example.com/foo https://192.168.4.100/foo
... i.e. access Machine A by name and by IP.
Every once in a while, you'll get a "400 Bad Request" response with the text
"Your browser sent a request that this server could not understand." Examining
the logs shows that the error occurred at the origin server, and that it
rejected a request whose "Host" was "192.168.4.100" and whose SNI was
"dmz.example.com". So the "browser" is really the Apache server on Machine A.
I poked around in the source, and I have a hunch that this is what's happening
(though this is mostly just speculation):
Apache makes mod_proxy workers by URL. In my example there's exactly one
worker. Each worker has a pool of connections that gets reused (via HTTP
Keep-Alive). But SNI only happens before the very first "kept alive" request.
So if Apache serves a request for https://192.168.4.100/foo by reusing a
worker's connection whose SNI was "dmz.example.com", then that's bad.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
