Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <530B0B4B.4060509@apache.org>
Date: Mon, 24 Feb 2014 10:05:15 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
 rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
References: <20131125155541.66e19919@hub>	<5144800.Zjx3nWxCiJ@nudel>
	<5303793F.3090202@fifthhorseman.net>	<1575801.JdVB9GyR8S@nudel>
	<CAAR2etMPyqt4QXodAkJ4bKNrf6jctCJPx9WO=M6b1M7CaJPx7A@mail.gmail.com>
 <CAKQ1sVMHUziOKJ=9AdriuERiWjOJbM3VrxONSMvAYmXBnG8AYQ@mail.gmail.com>
In-Reply-To: 
 <CAKQ1sVMHUziOKJ=9AdriuERiWjOJbM3VrxONSMvAYmXBnG8AYQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Yann Ylavic wrote:
> There seem to be different questions in this thread regarding SNI.
> Maybe we can enumerate them first to see what's going on (at least I need to)
> 
> 1. What should the client-provided SNI be checked against?
> 1.1. for server or proxy-reverse
> 1.2. for proxy-forward/CONNECT
> 
> Possibilities are :
> 1.a. Host: header
> 1.b. Request-URI's hostname
> 1.c. ServerName/ServerAlias(es)
> 1.d. ap_get_server_name_for_url()
> 1.e. none
> 
> 2. What should the proxy-provided SNI be?
> 2.1. when ProxyPreserveHost is off
> 2.2. when ProxyPreserveHost is on
> 
> Possibilities are :
> 2.a. proxy worker's hostname
> 2.b. r->hostname
> 2.c. Host: header (being sent)
> 
> 3. What should the backend's CN be checked against?
> 
> 4. How should the proxy reuse SNI connections?
> 
> Currently :
> 1.1 => 1.b if any, otherwise 1.a
> 1.2 => 1.e
> 2.1 => 2.a
> 2.2 => 2.b
> 3 => the proxy-provided SNI (or wildcard match)
> 4 => always
> 
> 
> I propose to use the following instead :
> 
> 1.1 => 1.d
> So that the admin can configure UseCanonicalName to branch 1.b-a or 1.c.

Host header and SNI should be consistent IMHO. So I think the current setup is correct.

> 
> 1.2 => 1.b
> It seems that the client-provided SNI is the requested backend (not
> the proxy), although I may be wrong.

Keep in mind that 1.e is only the current state on trunk and SNI checking IMHO makes no sense in the 1.2 case
as it cannot be used for virtual host selection on our side. This information is for the proxied side.

> 
> 2.1 => 2.c
> 2.2 => 2.c
> Both should use the Host: header since this is what the backend will check.
> Either the Host: is legitimate and we can forward it, or it should be
> denied by the proxy before forwarding (that's kind of hot potato sent
> to the backend otherwise).

I strongly disagree. In the 2.1 case we need to set the host header and SNI (provided no IP) as requested
by the admin. This configuration is usually on purpose and takes into account that the internal servers have
different DNS names and a matching certificate / virtual host setup.
Regarding 2.2 I think that 2.b is still the correct choice as we use a sanitized and normalized version of the
host header here.

> 
> 3 => the proxy-provided SNI (or wildcard match)
> Same as currently, but now this is really what was requested, whatever
> ProxyPreserveHost is.
> The SubjectAltName(s) should be used too.

ProxyCheckPeerName should do this already.

> 
> 4 => compare reusable connection's hostname with 2.c (when conn->is_ssl only)

This could be a worthwhile idea and I have seen your patch in bugzilla.
For ease of commenting I would like you to post it here such that inline comments could
be made (I would have some).

Regards

Rüdiger