[squid-users] Squid 3 SSL bump: Google drive application could not connect

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Sounds good,

but server world is not end on Linux. ;)

Now exists another *NIX systems. And will exists further.

Also. I have an idea, gents.

Do we can easy and quickly detect SSL Pinned destinations? And remember
it, for example, in database?

In another words - both problems is similar. Either non-HTTPS traffic
over 443 port, or pinned certs.

Can we detect both of them automatically and add to exclude list?

WBR, Yuri

05.01.2015 8:44, Eliezer Croitoru пишет:
> Hey Thread(Jason,Yuri,Douglas...),
>
> There are couple aspects about the ssl and connections in general and
> as we talk about ssl port I first would like to put couple things on
> the table.
>
> * Squid is a http caching proxy and there for every feature which is
> out of the http related scope should not be handled by squid at all.
> * Any squid operation is an application level and there for is limited
> by the software(kernel + squid).
> * There is a difference between servers taking a load of 1k requests
> per second to a SMB which handles about 50 requests per second.
>
> In general it's better to not intercept a connection which is not
> bump-able.
> The decision about if to DROP\REJECT or ACCEPT the connection should
> better not involve squid in general if possible.
> Squid offers a very nice interface but if you compare the Linux kernel
> forwarding capabilities compared to squid you would see that squid is
> very limited in the userspace.
>
> So in a case the helper only needs to "know" if the connection is
> bump-able there are other alternatives in the Linux kernel!!
> And if you need logs.. you can use the *helper*(which one you ever
> choose to work with) to log...
>
> So now for the real thing:
> My opinion about external_acl vs other solutions is that if squid with
> an external_acl works for you and you understand what it means from
> performance and security aspects try it, test it and then use it.
>
> But if your squid load is high and in the case squid slows down the
> bumped connections too much(compared to linux forwarding) I would try
> to use something like NFQUEUE to just test if the connection is
> bump-able or not by IP and DST PORT.
>
>  * some information about NFQUEUE
> https://home.regit.org/netfilter-en/using-nfqueue-and-libnetfilter_queue/
> http://suricata-ids.org/
>
> * Some examples:
>
https://www.wzdftpd.net/redmine/projects/nfqueue-bindings/repository/entry/examples/rewrite.py
> http://danmcinerney.org/reliable-dns-spoofing-with-python-scapy-nfqueue/
> http://5d4a.wordpress.com/2011/08/25/having-fun-with-nfqueue-and-scapy/
>
> A squid helper is nice but... a NFQUEUE helper that can verify if to
> FORWARD or BUMP the connection would be a better suited solution to my
> opinion.
>
> All The Bests,
> Eliezer Croitoru
>
> On 01/05/2015 03:07 AM, Douglas Davenport wrote:
> > Seems to me it would be more useful as an external ACL so that a
> > decision could be made based on other factors eg src or dstdomain
> > whether to deny or allow the un-bumpable connection.
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBAgAGBQJUqk4WAAoJENNXIZxhPexGWNoH/Ak2w0TZ+fU2Jy1bIOgWP82V
P5UJmB3DDSRwrqi4Y/bfUDGT1V3Cbjn8/RRTqTl7lSbBwGpSd8wSLGSTua6mqMY6
OIedOB7oBrJ9p8d1F7//ZsBrvGHequnD7Zp1DvBXVcptcVvFi56oAeFNjhRk1tcN
8EX2mkvgrDye7o7RRXPw1ukxbAJ0883A+gO3XpSARMUQEhsXJFFoygHUo7OIjdr+
oBrv/aypN8VOFvkHj50vDwtt4Rq7PPDYJRtHms2cIGsjK4+P1Rt1lxhr0GC/qbtZ
rfqIvP5LRmkID/lvHFhWC38APdjsgCcTICuJoPgKGDPX9YMAWtKdznu2XYpHNfw=
=LZkA
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150105/f666862b/attachment-0001.html>