Amos,
I knew something wasn't right.
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.
So that being said. I'm going to lose squidguard. Upgrade squid to 3.5.
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?
Thanks again. This is the first definitive answer I've gotten!.
On Tue, Nov 17, 2015 at 2:53 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
