On 6/07/15 2:01 am, Walter H. wrote:
reply_header_access Public-Key-Pins deny all
but this doesn't really work; is there another way?
If you think you can override all pinning options, then I'm afraid
you're mistaken. Well written security apps should do their darndest to
stop TLS intercept from working: eg hardwiring the CA cert into the
application itself and barfing if it ever starts a HTTPS connection that
isn't signed by their "one" CA
You have to accept that and configure for it: simply create a
"noSSLintercept" acl and in there place the ones that can't be fiddled
with. I'm still only testing TLS intercept myself, but so far I've only
whitelisted the following
.preyproject.com
accounts.google.com
.push.hello.firefox.com
BTW, even though Chrome/Firefox support key pinning, as a general rule
they actually support TLS intercept as well - in that if they detect the
CA involved in a cert-chain is trusted by the *user* and is not a
"commercial" CA, then they assume TLS Intercept must be involved and
allow it to work (at least that's how it seems to work to me). Not a bad
idea as it allows companies to do TLS intercept, but still guards
against governments forcing commercial CAs to create "fake" server certs
(let's be honest - all of this is about stopping government snooping -
not about normal criminal behavior)
Jason
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
