On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
