<div dir="ltr">Amos,<div><br></div><div>I knew something wasn't right. </div><div><br></div><div>Ok then I'm going to start there.  I had a heck of a time getting squidguard to even work due to its reliance on old berkely db packages, I'd be happy to see it go.   </div><div><br></div><div>So that being said. I'm going to lose squidguard.  Upgrade squid to 3.5.  </div><div><br></div><div>I haven't even looked at the 3.5 stuff.  How big of a config change am I looking at?  That being said, upgrade or start fresh? </div><div><br></div><div>Thanks again. This is the first definitive answer I've gotten!. </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 2:53 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 18/11/2015 7:46 a.m., Bruce Markey wrote:<br>
> So I "think" I have squid working with https, but to be honest I'm not<br>
> really sure.  Hopefully someone can point me in the right direction.<br>
><br>
> We're using squid as a transparent NON caching proxy.  It's basically only<br>
> there to give us insight into what everyone is using the web for.  From<br>
> there we'll do some blacklisting via squidguard.<br>
><br>
> I'm running centos 7, squid installed via yum.  Squid version 3.3.8.<br>
><br>
<br>
</span>SSL-Bump is a feature participating in an "arms race". The situation is<br>
very volatile and things continue to change fast as the worlds use of<br>
TLS improves, and the functionality in Squid changes to match it.<br>
<br>
You basically need to use the very latest Squid Squid release for it to<br>
work properly. Today that means 3.5.10 or later.<br>
<br>
You can find more recent packages for CentOS at the repositories listed<br>
in <<a href="http://wiki.squid-cache.org/KnowledgeBase/CentOS" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/KnowledgeBase/CentOS</a>><br>
<span class=""><br>
<br>
> Here are my questions.<br>
><br>
> 1. If ssl_bump is working correctly what should I be seeing in my<br>
> access.log?  Something like this?<br>
> 1447785601.904 240239 192.168.203.100 TCP_MISS/200 4876 CONNECT<br>
> <a href="http://173.194.207.113:443" rel="noreferrer" target="_blank">173.194.207.113:443</a> - HIER_DIRECT/<a href="http://173.194.207.113" rel="noreferrer" target="_blank">173.194.207.113</a> -<br>
><br>
> 2. What should ssl_bump be set to?  Right now it's set to ssl_bump none<br>
> all.   I don't think I'm seeing the traffic in the logs.  I changed this<br>
> and instantly started seeing https in the log BUT could not connect.<br>
> Browser errors.  Yes I understand how MITM works but I'm not sure what<br>
> exactly I'm supposed to be seeing here.   I assume if this was working<br>
> correctly i'd have push out the self signed cert I used for squid to<br>
> everyone.<br>
<br>
</span>Depends on what you are connecting to. But 3.3 series are not capable of<br>
working around the "certifiate pinning" features that are becomming<br>
popular in browsers.<br>
<span class=""><br>
><br>
> 3.  I'm not able to block https sites with squidguard.  I think this is due<br>
> to my https proxying not being correct.  I'm just not sure what exactly to<br>
> look for to troubleshoot.<br>
<br>
</span>SG is not capable of HTTPS. It "blocks" traffic by causing the client to<br>
be sent to a HTTP URL. Browsers do not like doing this and some will<br>
error. Older versions of Squid would not correctly perform the outgoing<br>
connection when intercepted traffic was sent over plain-text even if the<br>
URL was http://.<br>
<br>
Also, SG is a dead software and no longer maintained. Everything it does<br>
is able to be written as squid.conf ACLs instead.<br>
<span class=""><br>
<br>
><br>
> At the end of the day all I'd like to be able to do is quantify where<br>
> people are going, both http and https and to be able to blacklist certain<br>
> sites.<br>
<br>
</span>That is best done with the peek-and-splice functionality of Squid-3.5.<br>
Where you can peek to see from SNI where the client was going, then<br>
terminate or splice based on that. No need for decryption to complicate<br>
things most of the time, but you will still need to setup certs for the<br>
(declining) edge cases where it is still necessary.<br>
<br>
Amos<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br></div>