Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <5303793F.3090202@fifthhorseman.net>
Date: Tue, 18 Feb 2014 10:16:15 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.2.0
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> <52943239.9080607@velox.ch>
 <52B08B76.6060600@velox.ch> <5144800.Zjx3nWxCiJ@nudel>
In-Reply-To: <5144800.Zjx3nWxCiJ@nudel>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="5uFiFTMIOdSoTgMKENMMdjNsDlaV34CqR"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5uFiFTMIOdSoTgMKENMMdjNsDlaV34CqR
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 02/18/2014 08:14 AM, Pavel Mat=C4=9Bja wrote:

> There is one big risk when someone uses reverse HTTPS proxy with Server=
Alias.
>=20
> Let say you have on both - backend and proxy servers options:
> ServerName www.example.com
> ServerAlias example.com
>=20
> In old non-SNI days everything was working just fine.
>=20
> Now when one client connects to proxy and requires www.example.com, con=
nection=20
> is established to backend server with SNI hostname set to www.example.c=
om.
> Second client connects to proxy and requires example.com. Worker is mat=
ched=20
> because there is just one. Connection is reused but you will get 4xx Ba=
d=20
> Request because there is mismatch between old and current SNI hostname.=


It seems like an administrator could avoid this risk by doing hostname
canonicalization via external redirect at the proxy itself.  This
probably isn't a currently common practice, but for sites who should
canonicalize their hostnames, i don't see it as particularly onerous.

The main concern would be for non-canonicalized hostnames.  e.g.
*.example.com, where each user of a service gets to set up
https://$USERNAME.example.com/.  A proxy would need to pass this
information through to the origin server -- so in the scenario you
describe, a reverse proxy could run into serious trouble.

	--dkg


--5uFiFTMIOdSoTgMKENMMdjNsDlaV34CqR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTA3k/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcNTIP/2RFzgqhJp16RD23smwMsGHh
cTqO1qUCf19gowiRUx87XvVUl0FOO+PxtIROFHbWsNWMsW2nCtXyw+C0I7vGRCTc
XW5iK9wV9nFoEzn+oF9dVOPPSOzk3kjQCW35U1JTEQ9o5DuE1N5m343g/azjQukI
22RBBcPYK6Iv8lUPaMrNhkrXMrmB41wPlMQAJ1VmJUZV8Tab6rhSbYfbJ1McPtYh
gbGdLibaAdxmNfc+l8Drv0rqJtusRYpLMDkSRjqytBRrxlarSP5mo1IFe8ZGkelM
NO8qOT9TiS8/W9x0CxO67XZp6s6wU3HTZkQjtQXDULjeBvHCsI4tX/Hmq0eIw3af
vOKoQyQKmxoCBr8oIBdYqfJdj/GUEHMs/iPsIdDN2ew8/YU74d0c7oeOBczQ7EVq
Y72WKAQphqeue5YfYvdQbwxoymPxw2XZkeDD2GRpeJmddShHusDS2082KuvfeVpC
fLQDBzy5xYF5GclZWupmiHisJVoKZrDErwmlJ7oSjrJ1yX/k0fH4vrsgXf7/FjYu
RwWgjUbB9K/UursTg7naj3ja7PUkSmyLX5gJLXeEJZgH3KxkI/knaCscTGmz0qD2
N3ciPQatj7hx5SLE4KV7yY2Ig3tzCPmO+VqSghPbpxjA3nx5mnoH9/dpKK6V0TY3
sLQxyt7Jby7i5yZU/5jM
=gNs6
-----END PGP SIGNATURE-----

--5uFiFTMIOdSoTgMKENMMdjNsDlaV34CqR--