On 18/11/2015 7:46 a.m., Bruce Markey wrote: > So I "think" I have squid working with https, but to be honest I'm not > really sure. Hopefully someone can point me in the right direction. > > We're using squid as a transparent NON caching proxy. It's basically only > there to give us insight into what everyone is using the web for. From > there we'll do some blacklisting via squidguard. > > I'm running centos 7, squid installed via yum. Squid version 3.3.8. > SSL-Bump is a feature participating in an "arms race". The situation is very volatile and things continue to change fast as the worlds use of TLS improves, and the functionality in Squid changes to match it. You basically need to use the very latest Squid Squid release for it to work properly. Today that means 3.5.10 or later. You can find more recent packages for CentOS at the repositories listed in <http://wiki.squid-cache.org/KnowledgeBase/CentOS> > Here are my questions. > > 1. If ssl_bump is working correctly what should I be seeing in my > access.log? Something like this? > 1447785601.904 240239 192.168.203.100 TCP_MISS/200 4876 CONNECT > 173.194.207.113:443 - HIER_DIRECT/173.194.207.113 - > > 2. What should ssl_bump be set to? Right now it's set to ssl_bump none > all. I don't think I'm seeing the traffic in the logs. I changed this > and instantly started seeing https in the log BUT could not connect. > Browser errors. Yes I understand how MITM works but I'm not sure what > exactly I'm supposed to be seeing here. I assume if this was working > correctly i'd have push out the self signed cert I used for squid to > everyone. Depends on what you are connecting to. But 3.3 series are not capable of working around the "certifiate pinning" features that are becomming popular in browsers. > > 3. I'm not able to block https sites with squidguard. I think this is due > to my https proxying not being correct. I'm just not sure what exactly to > look for to troubleshoot. SG is not capable of HTTPS. It "blocks" traffic by causing the client to be sent to a HTTP URL. Browsers do not like doing this and some will error. Older versions of Squid would not correctly perform the outgoing connection when intercepted traffic was sent over plain-text even if the URL was http://. Also, SG is a dead software and no longer maintained. Everything it does is able to be written as squid.conf ACLs instead. > > At the end of the day all I'd like to be able to do is quantify where > people are going, both http and https and to be able to blacklist certain > sites. That is best done with the peek-and-splice functionality of Squid-3.5. Where you can peek to see from SNI where the client was going, then terminate or splice based on that. No need for decryption to complicate things most of the time, but you will still need to setup certs for the (declining) edge cases where it is still necessary. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
