Re: [SQU] SSL Gatewaying

Hi,

With SSL and forwarding proxies you have three options:

1) browser to proxy = https
   proxy to server = http

2) browser to proxy = http
   proxy to server = https

3) browser to proxy = https (one session)
   proxy to server = https (DIFFERENT session)

You can never have "transparent" proxying because the entire packet is
encrypted. The proxy cannot decrypt the packet to find out which server to
forward to. That's also why you cannot have virtual named servers in web
servers (one IP address and multiple servers) - some server must decrypt
the packet to find the virtual server to send the packet to. The packet
can't be re-encrypted so the whole scheme falls down.

Other answers inline.

On Wed, 21 Feb 2001, John Castillo wrote:

> the SSL Gatewaying patch worked out. thanks for the autoheader and autoconf
> information. presently i have a working SSL Gateway for my Transparent
> Reverse Proxy configuration!
>
> CLIENT <--- over HTTPS ---> SQUIDPROXY <--- over http ---> INTERNALRESOURCE
>
> however, NOW i'm told that the connection between the SQUIDPROXY and
> INTERNALRESOUCE also needs to be done over https. i have already tested the
> current config and noticed that i get the expected error of Connection
> Failed (111) Connection Refused. i would assume that this is because
> SQUIDPROXY is trying to access the INTERNALRESOUCE over http, when the
> INTERNALRESOURCE will only work over https.
>
> so the new question is:
> 1 - can i use a SSL wrapper (like stunnel or sslwrap) to create the secure
> connection i need from SQUIDPROXY to INTERNALRESOURCE?

That should work.

> 2 - is this setup hokey or what?

Within the bounds of the capabilities of the software and complications
introduced by encryption, no. The only "other" way to do this is to use a
"plug-gw" (in TIS fwtk parlance). The browser connects to the plug-gw
running on the external system. Only this plug is allowed through the
firewall and it just forwards the bytes it receives from browser to
internal server. Traffic the other way goes server-plug-browser. Of course
doing this places a *LOT* of trust in the internal server. IMHO, a better
solution is to put the internal server on a DMZ off a firewall. This
limits what can be sent to the server and protects "inside" in the event
the server gets broken. Insiders can still get to it too.

> 3 - i found that Iplanet Proxy (Netscape Proxy) can natively handle this
> sort of secure client to proxy, secure proxy to internal resource
> connection. i wonder if it is capable of doing it transparently for the
> client and i also wonder if its doing this "double encryption".

As stated above, yes. That's because I read it in the (Netscape) proxy
server book.

Colin

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html