On Thu, 5 Aug 2004, Peter Arnold wrote:
Technically it is possible to implement a decrypting proxy using spoofed server certificates issued by the proxy, but this has not
yet been implemented in Squid. The technical drawbacks from doing this is
Is this the case even with the ssl patch for squid 2.5? I've been trying to get something to work for a while now but haven't been able to nut it out. I was thinking it might work to reverse proxy and sslproxy a list of known ssl email sites but I've not been able to find much info on this particular scenario..... now I know why.
The SSL update patch for 2.5 adds better SSL server functionality, and the ability to connect to https:// sites. There is still several pieces of missing to make the requested functionality.
You may have some limited success in a transparent proxy environment redirecting port 443 to an https_port of Squid-3.0, but clients will complain loudly about the certificate not being valid/correct.
- End-to-end is violated, making it impossible to use/access sites requiring client side SSL certificates for authentication.
Could squid be configured to ACL what does and doesn't get decrypted/encrypted?
In theory yes, and quite likely would get done in such manner when the feature of decrypting proxied https straffic is implemented.
Note: This technology can only be made to work reasonably in a proxied environment. Transparent interception of port 443 won't work good.
What is missing from Squid-3 is
- Ability to intercept CONNECT request and transform them into an SSL request as if the request had arrived on an https_port.
- A faked CA generating temporary certificates for the requested host names to make clients happy. All clients must be configured to trust this CA.
- An interface of Squid where it asks and caches server certificates from the faked CA as needed. This CA may eventually be built-in to Squid but should start it's life as an external helper.
Regards Henrik
