On Mon, 13 Dec 2004, Ow Mun Heng wrote:
So essentially this means that whatever's being transferred from the client (via HTTPS), once it reaches the squid box, it will be sent un-encrypted to the server?
Lets put it this way:
any requests accepted by the https_port directive is decrypted by Squid.
Squid-2.5 (without SSL update) is not capable of encrypting requests, or in other words can not initiate a https request to the backed server, only http requests (or ftp if you like..).
With Squid-3 (or 2.5 + SSL update) you can ask Squid to reencrypt the requests to the backend servers. Most easily via the cache_peer directive.
All of this is only related to reverse proxies acting as web servers to the clients. In forward proxies to the Internet things works very differently using the CONNECT proxy method. The CONNECT method is never seen in reverse proxies and only exists between browsers and their Internet proxies for opening tunnels to Internet servers.
I believe all these are the requirements, if one were to run squid as a surrograte proxy (in front) of a web-server (???)
Depends on what you want to do. Most people doing this likes Squid to handle the SSL part allowing the web server to focus on the application.
But if your application depends on client-side certificates then terminating the SSL connection infront of the application server is not an option and you must publish the web server directly on the Internet without any surrogate server infront. This because the SSL handshake involving client certificates requires a direct connection between the client and the server.
Regards Henrik
