OT: Apache as reverse SSL proxy

Matthew Seaman m.seaman at infracaninophile.co.uk
Tue Oct 5 05:33:33 UTC 2010


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...
>>
>>
> 
> You could circumvent that issue by terminating your HTTPS sessions on
> the reverse proxy itself (and talk HTTP to the application server). Some
> 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

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20101005/41c7e1ce/signature.pgp


More information about the freebsd-questions mailing list