Re: [squid-users] feature request for sslbump

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.
Received on Fri Jul 18 2014 - 05:12:09 MDT