Re: [squid-users] SSL Accel - Reverse Proxy

On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> You could make a second peer connection using HTTPS between squid and the
> back-end server and ACL the traffic so that only requests coming in via SSL
> are sent over that link. Leaving non-HTTPS incoming going over the old HTTP
> link fro whatever the server want to do.
>
Thanks Amos

Not sure that I made myself clear or that I understand your suggestion.

I need to allow squid to connect and talk to my servers via http
(only), i want squid to handle the SSL termination (SSL acceleration,
take the overhead off the back end servers).

However since squid talks to the back end servers via http (and not
https on pages that require https), I need to somehow tell the server
that the original connection, or the connection that will go back to
the client will be https, even though the server is responding via
http..

I handle secure and non secure fine now, the same website for example.
apps.domain.com, listens to both 443 and 80, so squid can handle
secure and non secure. there is code on apps.domain.com that checks
the incoming protocol to verify that's it's secure, if not it sends a
secure url for the client to come back in on. As you can see if I
allow Squid to handle the SSL portion, the back end server has no way
of knowing (the piece I'm missing) if the actual client connection is
secure or not. (hard to explain possibly)..

Client ----> apps.domain.com (443) <Squid> ---------> backend server (80)
backend server (80) ------> <Squid> apps.domain.com (443) ---------->
Client (443)

I'm wondering if Squid can tell the peer (server) that the original
request was in fact secure, so that we can tell the application, feel
free to respond with the secure data via non secure port, because
squid will encrypt the server response and get back to the client via
https

Sorry kind of long winded.
Tory
Received on Thu May 01 2008 - 16:21:02 MDT