Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <51663F86.2010302@velox.ch>
Date: Thu, 11 Apr 2013 06:43:50 +0200
From: Kaspar Brand <httpd-dev.2013@velox.ch>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: use connection hostname for SNI and SSLProxyCheckPeerCN instead
 of the Host: header
References: <CD8A0375.2AAF0%eugenel@amazon.com>
In-Reply-To: <CD8A0375.2AAF0%eugenel@amazon.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.04.2013 02:49, Lam, Eugene wrote:
> Was "Re: SSLProxyCheckPeerCN / ProxyPreserveHost issue"
> 
> So, what do folks think about adding this directive to use the
> connection hostname for SNI and the SSLProxyCheckPeerCN feature?
> Would such a directive be beneficial?  It seems a number of users who
> use ProxyPreserveHost will benefit from this.  It lets users revert
> to the behavior before the SNI change.

It's not really "the SNI change" which is the issue, it's the question
of whether you want to ignore cert name mismatches. From your PR:

> ssl_engine_io.c will pull out this note and use it for SNI and
> SSLProxyCheckPeerCN.  Unfortunately, www.example.com does not match
> backend.example.com.

I wouldn't call this unfortunate, I would say that it's a
misunderstanding of what SSL proxying with mod_proxy_http is expected to
provide.

> The reverse proxy shouldn't expect CN=www.example.com,
> CN=www.example.org, etc. when the backend only has
> CN=backend.example.com.

Looks like you're trying to use a "generic" SSL tunnel for any HTTP
request, irrespective of the host name in its URL. This is prone to MitM
attacks, and hardly a good idea. See also this message:

http://mail-archives.apache.org/mod_mbox/httpd-dev/201204.mbox/%3C4F8E7873.8000004%40velox.ch%3E

Kaspar