Search squid archive

Re: feature request for sslbump

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Several ssl inspecting firewalls also provide this capability.

Sent from my iPhone

> On Jul 14, 2014, at 6:10 PM, Brendan Kearney <bpk678@xxxxxxxxx> 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.
> 




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux