httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 55422] New: mod_proxy's HTTPS client generates bad requests with Host != SSL_TLS_SNI
Date Thu, 15 Aug 2013 16:08:46 GMT
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: bugs@httpd.apache.org
          Reporter: csdillard@gmail.com

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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message