I have to remark, this is one of the significant downsides of people going all-out SSL, including that in order for many security technologies to properly inspect attacks they must also do similar ssl-bumping. sigh. Best regards, The Geek Guy Lawrence Pingree http://www.lawrencepingree.com/resume/ Author of "The Manager's Guide to Becoming Great" http://www.Management-Book.com -----Original Message----- From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] Sent: Saturday, June 14, 2014 10:12 AM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: Re: squid with qlproxy on fedora 20 not working for https traffic On 06/13/2014 09:10 PM, Amos Jeffries wrote: > On 14/06/2014 1:23 p.m., MrErr wrote: >> Does this mean that dstdomain does not work with ssl-bump? > Yes and no. It works with CONNECT bumping in regular proxy traffic. ... unless the browser uses IP addresses in CONNECT requests (some do) or the user types in (or clicks on a link with) an IP address instead of a domain name (rare and does not work well for the user even without SslBump, but does happen in reality so be ready for it). > It does not work on intercepted port 443 traffic reliably. In summary, bumping SSL does not and cannot work reliably in most environments. There will always be broken cases despite our continuing efforts to minimize SslBump invasiveness. If user happiness is important, be prepared to babysit your Squid and add low-level (TCP/IP-based) exceptions. >> My other reason for not using "ssl-bump server-first all" is that the >> kindle fire stops working. I read that it was because of something >> called ssl pinning. So i do need to get some kind of targeted bumping to happen. >> > > HSTS probably. And yes those sites bumping does not work for. There is also bug 3966 that affects some sites, including Google-affiliated sites, in some environments: http://bugs.squid-cache.org/show_bug.cgi?id=3966 Cheers, Alex.
