|
-----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@xxxxxxxxxxxxxxxxxxxxx > 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----- |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
