Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E9CD410B42 for ; Tue, 26 Nov 2013 08:30:17 +0000 (UTC) Received: (qmail 36109 invoked by uid 500); 26 Nov 2013 08:30:14 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 35920 invoked by uid 500); 26 Nov 2013 08:30:10 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 35906 invoked by uid 99); 26 Nov 2013 08:30:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Nov 2013 08:30:09 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ylavic.dev@gmail.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Nov 2013 08:30:05 +0000 Received: by mail-ie0-f175.google.com with SMTP id x13so8825641ief.34 for ; Tue, 26 Nov 2013 00:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XKTX+yIwE4iWBFYSpUVBYhJ2KNCUYn0R1IrXywyoR4I=; b=M1QbtDLhpA/rJKVfSb0+0MDceg2QmhrY19/HsFrYpqBE4bLW2RyPTJ0WQE+Tu7kqGZ ra/9DVtEEO7GtLa0M/Wr2ZTVy2YKQ5TAw2/vLIWcqWJ4OsIa1ET9WJjtIAMaf//Uj1Cc OrdDrCqAyxY7Zkj7U6QnQ2djLBab1et17QLjYPlPIVY5ELKXf8WgAOfrwiZ5whevkuip tJ64FSeIUYzzOwr7EGjXfTPu1j9wwv+ts2kAWHtxBS9j6TkyuwRUL1djtoj1d97tqBCt 4y+t859yaPF2ads0xyqbGvibNKrsw39+QLyWbGfQTE2bkYD3uOv5hH131nPSxqeYEsBn qujA== MIME-Version: 1.0 X-Received: by 10.50.57.44 with SMTP id f12mr15838041igq.39.1385454584639; Tue, 26 Nov 2013 00:29:44 -0800 (PST) Received: by 10.43.133.70 with HTTP; Tue, 26 Nov 2013 00:29:44 -0800 (PST) In-Reply-To: <52943239.9080607@velox.ch> References: <20131125155541.66e19919@hub> <52943239.9080607@velox.ch> Date: Tue, 26 Nov 2013 09:29:44 +0100 Message-ID: Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests From: Yann Ylavic To: dev@httpd.apache.org Content-Type: multipart/alternative; boundary=e89a8ff24d9d5eb67204ec10484d X-Virus-Checked: Checked by ClamAV on apache.org --e89a8ff24d9d5eb67204ec10484d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand wrote: > On 26.11.2013 00:46, Yann Ylavic wrote: > >> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT > >> requests alone, or all forward proxy requests? > >> > >> > > Maybe all forward proxy modules are concerned. > > There is PR > > 55782 > > which I started to debug but did not finish (run out of time). > > From there it looked like ProxyPassPreserveHost may cause problems too > > with SNI (not sure yet). > > > > Anyway, shouldn't the proxy code(s) use the Host header to fill in the > SNI > > from r->headers_in (when applicable), instead of r->hostname, at least > for > > the CONNECT and ProxyPassPreserveHost cases? > > AFAICT, this was the idea in the original patch for PR 53134, but a > "slightly different approach" was then committed (r1333969). > > As far as PR 55782 is concerned, the problem might be that > proxy_util.c:ap_proxy_determine_connection() does not take Host: header > differences into account when checking if an existing connection can be > reused (not sure). With SNI this would have the effect that the hostname > from the TLS handshake is causing the mismatch with the Host: header. > ap_proxy_determine_connection() should only care about IP:port reuse, which can be even if the Host has changed. But indeed the Host is really what the origin server will use, so IMHO this is the one to use for SNI in proxy_http_handler (should it differ from r->hostname). Another point is that SNI can not be an IP address according to the RFC 6066 : 3. Server Name Indication [...] Literal IPv4 and IPv6 addresses are not permitted in "HostName". and this is not specifically checked by mod_proxy before filling SNI. Shouldn't the SNI be ommited when the Host is missing/empty or an IP address too? > > Kaspar > --e89a8ff24d9d5eb67204ec10484d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 26, 2013 at 6:31 AM, Kaspar Brand <httpd-dev.2013@velox.ch> wrote:
On 26.1= 1.2013 00:46, Yann Ylavic wrote:
>> Ideas for the appropriate patch to httpd? =A0Scope this fix to CON= NECT
>> requests alone, or all forward proxy requests?
>>
>>
> Maybe all forward proxy modules are concerned.
> There is PR
> 55782
> =A0which I started to debug but did not finish (run out of time).
> From there it looked like ProxyPassPreserveHost may cause problems too=
> with SNI (not sure yet).
>
> Anyway, shouldn't the proxy code(s) use the Host header to fill in= the SNI
> from r->headers_in (when applicable), instead of r->hostname, at= least for
> the CONNECT and ProxyPassPreserveHost cases?

AFAICT, this was the idea in the original patch for PR 53134, but a "slightly different approach" was then committed (r1333969).

As far as PR 55782 is concerned, the problem might be that
proxy_util.c:ap_proxy_determine_connection() does not take Host: header
differences into account when checking if an existing connection can be
reused (not sure). With SNI this would have the effect that the hostname from the TLS handshake is causing the mismatch with the Host: header.

ap_proxy_determine_connection() should only care abo= ut IP:port reuse, which can be even if the Host has changed.

But indeed the Host is really what the origin server = will use, so IMHO this is the one to use for SNI in proxy_http_handler (sho= uld it differ from r->hostname).

Another point is that SNI can not be an IP addr= ess according to the RFC 6066 :
3.  Server Name Indication
=A0  =
[...]

=A0  Literal IPv4 and IPv6 addresses are not permitted in "HostName&qu=
ot;.
and this is not specifically checked by mod_proxy before filling S= NI.

Shouldn't the SNI be ommited when the Host is missing/empty = or an IP address too?
=A0

Kaspar

--e89a8ff24d9d5eb67204ec10484d--