Re: [squid-users] feature request for sslbump

From: Lawrence Pingree <geekguy_at_geek-guy.com>
Date: Mon, 14 Jul 2014 18:25:20 -0700

Several ssl inspecting firewalls also provide this capability.

Sent from my iPhone

> On Jul 14, 2014, at 6:10 PM, Brendan Kearney <bpk678_at_gmail.com> wrote:
>
>> 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.
>
Received on Tue Jul 15 2014 - 01:25:34 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 15 2014 - 12:00:08 MDT