On Mon, 2014-07-14 at 15:57 +1200, Jason Haar wrote: > Hi there > > I've started testing sslbump with "ssl_bump server-first" and have > noticed something (squid-3.4.5) > > 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 > > The problem with that model is that it means no-one can get to websites > using self-signed certs. Using "sslproxy_cert_adapt" to allow such > self-signed certs is not a good idea - as then squid is effectively > legitimizing the server - which may be a Very Bad Thing > > 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? :-) > > Thanks > an unnamed enterprise vendor provides the "Preserve Untrusted Issuer" functionality, very much like you describe. it leaves the decision to the user whether or not to accept the untrusted cert. the cert needs to be valid (within its dates), and match the URL exactly or via wildcarding or SAN to be allowed, too. since i have not started intercepting ssl with squid yet, i have not run into this scenario or contemplated what i would look to do in it.
