It appears that our SNI hostname comparison is invalid for forward proxy
applications, specifically proxy CONNECT. RFC 2616 states;
14.23 Host
The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original
URI given by the user or referring resource (generally an HTTP URL,
as described in section 3.2.2). The Host field value MUST represent
the naming authority of the origin server or gateway given by the
original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address.
I had read this as proxy host's name in forward proxy applications, but
reading on, it's clear this is ambiguous; from RFC 2817
5.2 Requesting a Tunnel with CONNECT
A CONNECT method requests that a proxy establish a tunnel connection
on its behalf. The Request-URI portion of the Request-Line is always
an 'authority' as defined by URI Generic Syntax [2], which is to say
the host name and port number destination of the requested connection
separated by a colon:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
So we have a clear, RFC-approved example of using the final endpoint as
the Host: header value, not the intermediate proxy.example.com.
In this case, we fail the request because the SNI of the proxy machine
does not match the Host: of the origin server name.
Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
requests alone, or all forward proxy requests?
