Date: Tue, 05 Oct 2010 06:33:19 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Peter Boosten <peter@boosten.org> Cc: freebsd-questions@freebsd.org Subject: Re: OT: Apache as reverse SSL proxy Message-ID: <4CAAB89F.70907@infracaninophile.co.uk> In-Reply-To: <4CAAAC4A.5060106@boosten.org> References: <20101004221506.GA8662@polands.org> <AANLkTinCfhmyb1XVXOk4PiSs-MMRPJ4bjvkb6bYiiODJ@mail.gmail.com> <20101005035354.GB8662@polands.org> <4CAAAC4A.5060106@boosten.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFB8185613FCE3668D969454B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 05/10/2010 05:40:42, Peter Boosten wrote:
> On 5-10-2010 5:53, Doug Poland wrote:
>> On Mon, Oct 04, 2010 at 09:19:52PM -0500, Adam Vande More wrote:
>> The documentation for www/pound
>> indicated "HTTPS does not allow virtual hosting". I seem to recall
>> bumping into this issue in the past that one cannot do named-based
>> vhosts on HTTPS.
Yes. There's a catch-22 with HTTPS. The ServerName of the encrypted
website is part of the keying material used to decrypt the traffic.
That's given in the Host: header line in HTTP packets -- which is part
of the encrypted content. So to find the name of the virtual host you
need to decrypt the packet, but to decrypt the packet, you first need
the virtual host name. The only way it can work is by making a 1:1
association of web sites with IP numbers, as you can then work out the
server name from the IP connection.
Nowadays there is also the possibility of RFC2817 -- in essence you
start an ordinary HTTP session, then issue a STARTTLS command and
upgrade the connection to encrypted. This will allow name-based virtual
hosting with TLS to work as intended. Unfortunately, last I checked,
while apache supports this, most web browsers do not.
>> Look like it's back to the drawing board...
>>
>>
>=20
> You could circumvent that issue by terminating your HTTPS sessions on
> the reverse proxy itself (and talk HTTP to the application server). Som=
e
> applications won't work that way, but modern ones (and even Outlook Web=
> Access) can use a HTTPS-front-end. The problem exists within
> applications with hard-coded links.
In fact, you pretty much have to do that. Unless your proxy is going to
work at layer 2 only, which most people would recognise as a NAT'ing
gateway, and not something you'ld use apache to implement at all.
If your proxying software needs to work at layer 3 -- that is, the
proxy needs to be able to access the HTTP content wrapped inside the TLS
session, then the proxy has to be an endpoint of the TLS session.
Whether the proxy encrypts its own connections to the original source is
then just a matter of preference. [Well, that, and software capability:
squid used in reverse proxy mode will speak HTTPS to the end users, but
requires plaintext access to the origin servers.]
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enigFB8185613FCE3668D969454B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyquKcACgkQ8Mjk52CukIwAzwCbBDwERUg6/eeH9EP00U4UrY0Y
9KoAn0f4Duem9hyG+ZCPTQKjowWe3XjU
=chQF
-----END PGP SIGNATURE-----
--------------enigFB8185613FCE3668D969454B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CAAB89F.70907>