On 07/13/2014 09:57 PM, Jason Haar wrote: > If your clients have the "Proxy CA" cert installed and go to legitimate > https websites, then everything works perfectly (excluding Chrome with > it's pinning, but there's no way around that). However, if someone goes > to a https website with either a self-signed cert or a server cert > signed by an unknown CA, then squid generates a "legitimate" SSL cert > for the site, but shows the squid error page to the browser - telling > them the error If you tell Squid that self-signed and/or untrusted sites are OK for Squid to talk to, then Squid will not generate an error but will mimic site's self-signed or untrusted certificate instead. This can be further tuned using sslproxy_cert_sign, but the "default" sslproxy_cert_sign setting (after you allow said talking) should be what you want. > So I was thinking, how about if squid (upon noticing the external site > isn't trustworthy) generates a deliberate self-signed server cert itself > (ie not signed by the Proxy CA)? Then the browser would see the > untrusted cert, the user would get the popup asking if they want to > ignore cert errors, and can then choose whether to trust it or not. That > way the user can still get to sites using self-signed certs, and the > proxy gets to "see" into the content, potentially running AVs over > content/etc. > > ...or haven't I looked hard enough and this is already an option? :-) I think it is already supported for the reasons you specified. The key here is to allow _Squid_ to talk to untrusted servers. IIRC, this is done using sslproxy_cert_error. By default, Squid will not communicate with an untrusted server and will generate an error response (or terminate the transaction). Error responses require bumping trusted-by-client certificates, of course. If you trust your users more than you trust Squid (so to speak), then you should relax sslproxy_cert_error. HTH, Alex.
