Tory M Blue wrote:
On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries <[EMAIL PROTECTED]> 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.
You made the situation clear. I mentioned the only reasonably easy solution.
If you didn't understand me, Keith M Richad provided you with the exact
squid.conf settings I was talking about before.
Squid can talk HTTPS to the clients, HTTPS to the web server, and still
sit in the middle caching files. Exactly as it would for HTTP.
All you need is SSL certificates for each side of squid. Configured as
Keith gave you.
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
--
Please use Squid 2.6.STABLE20 or 3.0.STABLE5
