Re: reverse proxying SSL with open source software

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Sun, 07 Nov 1999 23:16:37 +0100

Paul Boyer wrote:

> From what Jeffrey wrote, it seems clearer the proper solution is
> more on the Apache side than the Squid one, so may be this post
> should go to an other list (any suggestions ?) but I can't beleive
> this has not yet been done on Squid and/or Apache, since it _IS_
> featured on Netscape proxy AND MS-Proxy.

In short why SSL does not provide SSL->HTTP gatewaying:
1. Not needed, there are other OpenSource products doing this.
2. Messy legal implications.

More detail:
Squids primary business is acting as a normal proxy server (not reverse
proxying), and then SSL support isn't needed. In a normal proxy SSL
traffic is tunnelled by the CONNECT method.

Adding SSL to Squid serverely restricts the distribution of the source.
The source set for SSL legal to use inside US is illegal to export, and
the source set legal to use outside US is illegal to import due to
patent restrictions. Also, even the weakest model is illegal to export
(or import) to some countries. The rules on cryptography varies from
country to country, and I prefer to stay out of that hairy nest as long
as possible.

If you need to have a SSL->HTTP gateway, then get one, or add SSL to
your Apache server. There are SSL->HTTP gateways build arount SSLeay or
OpenSSL if you need one.

Regarding the security of SSL: the cryptographic signature of the server
in SSL identifies the server in a much stronger context than the
IP/domain name alone, especially considering that both the domainname
and the private SSL key must match. A man-in-the-middle can only attack
SSL connections if they have access to a signed pricate key matching the
FQDN of the server, so you need to guard your servers key and preferably
have it protected by a pass phrase to be entered manually on each server
restart (that way an attacker would have a lot harder recovering your
key, even if they sucessfully break into your server). I would also
recommend the use of user certificates if you handle any sensitive
information. User certificates adds yet another layer of security and
then the man-in-the-middle needs to have access both to the servers and
users private key to be able to attack the connection (except for
one-shot connections like single form submission where the form is
loaded by other means than a verified SSL connection)

--
Henrik Nordstrom
Squid hacker
Received on Sun Nov 07 1999 - 15:25:28 MST

This archive was generated by hypermail pre-2.1.9 : Wed Apr 09 2008 - 11:57:32 MDT