<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA1 <br>
<br>
I think,<br>
<br>
non-HTTP/HTTPS security issues is never ever Squid function.<br>
<br>
Squid is not all-in-one-security-solution. It's only HTTP proxy.<br>
<br>
For others security breches (i.e SSH tunnels, various browser
tunnel-related plugins, Tor etc., ) we have another tools. Cisco
NBAR proticol discovery, other DPI solution.<br>
<br>
AFAIK, primitive Cisco extended ACL + tcpiputils.com and simple
sniffer can make miracles.<br>
<br>
Following I offer to retirn to the Earth and limit our functionality
as I said before. Just HTTP/HTTPS over 443 port.<br>
<br>
I understand that exists wonderful and overall solutions like
ufdbGuard. But we talk not about it.<br>
<br>
05.01.2015 17:51, Marcus Kool пишет:<br>
<span style="white-space: pre;">> Much of the discussion so far
has been about bumping traffic on port 443,<br>
> bumping SSL-encapsulated HTTP traffic and not bumping
(allowing)<br>
> other traffic. Since port 443 is used for many protocols, it
is in many<br>
> cases dangerous to allow non-bumpable traffic: SSH tunnels
using port 443<br>
> are common, so are VPNs. Do you know a security officer who
does not want<br>
> to block an SSH tunnel, or an app that can share corporate
documents<br>
> on public websites? If there is not more attention to these
kinds of<br>
> applications that use port 443 to circumvent corporate
firewalls,<br>
> Squid will be doomed to be used only in environments where
the priority<br>
> for security is low to non-existent. Just type "punching
holes in corporate<br>
> firewalls" or "ssh tunnel proxy" in Google to see how easy it
is to use an<br>
> SSH tunnel.<br>
><br>
> I am the author of ufdbGuard, a filter for Squid and besides
filtering<br>
> based on URLs, ufdbGuard also probes port 443 to see what
kind of traffic<br>
> the server is expecting. By using probes, ufdbGuard can
detect SSH tunnels,<br>
> popular chat protocols, etc. but it is not a 100% guaranteed
solution<br>
> because ufdbGuard cannot not see the traffic that flows
through the proxy,<br>
> i.e. there is not yet an interface for this type of traffic
inspection.<br>
><br>
> Marcus<br>
><br>
><br>
> On 01/05/2015 07:59 AM, Eliezer Croitoru wrote:<br>
> Hey Yuri,<br>
><br>
> Indeed there are other *NIX systems and for each and every
one of them<br>
> there is a solution in need.<br>
><br>
> SSL Pinned destinations cannot be identified automatically
since the<br>
> are pinned inside a software and the certificate will not
show<br>
> anything about that.<br>
> The basic tests we can do are:<br>
> - The host is using ssl or tls or not at all(based on the
selective<br>
> answer of the service)<br>
> -<br>
> - If the connection is using tls\ssl then inspect the
components of<br>
> the certificate(such as rootCA validation against the local
machine<br>
> certificates DB)<br>
><br>
> Depend on the goal of the certificate validation the decision
will be<br>
> made to either allow the connection "uninspected" or to
"bump" it as<br>
> is without any smart identification.<br>
><br>
> If indeed there is a database<br>
> sqlite3\mysql\postgres\redis\memcached\others it can be used
in the<br>
> iptables level.<br>
> Also a point in this DB and this cache is that it will be
persistent<br>
> so what so ever the *NIX system is there is an option once
the IP +<br>
> port was tagged as non-bump-able it is better be in the
FIREWALL level<br>
> override better then squid external_acl.<br>
> Reason: If the kernel does what it needs to do then squid
should not<br>
> touch the packets.<br>
> It's not always right but it's a point in the issue.<br>
> I still do not know how to work with NFQUEUE and I am sure
that there<br>
> is an option to make a fast decision and if not then let the<br>
> connection be BUMPED.<br>
><br>
> I have written a small golang script that can check couple
things<br>
> about the ssl session at:<br>
> <a class="moz-txt-link-freetext" href="http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go">http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go</a><br>
><br>
> Besides this helper there is another script which do couple
things in<br>
> another level.<br>
><br>
> ##########<br>
> If any thing will be decided for squid internals it will be
after a<br>
> proof of concept that we can implement together.<br>
> Can we take this thread to storm and put on the table a proof
of<br>
> concept logic for ssl inspection\bumping and bypassing?<br>
><br>
> Eliezer<br>
><br>
> On 01/05/2015 10:40 AM, Yuri Voinov wrote:<br>
> >>> Sounds good,<br>
> >>><br>
> >>> but server world is not end on Linux. ;)<br>
> >>><br>
> >>> Now exists another *NIX systems. And will exists
further.<br>
> >>><br>
> >>> Also. I have an idea, gents.<br>
> >>><br>
> >>> Do we can easy and quickly detect SSL Pinned
destinations? And<br>
> >>> remember it, for example, in database?<br>
> >>><br>
> >>> In another words - both problems is similar.
Either non-HTTPS<br>
> >>> traffic over 443 port, or pinned certs.<br>
> >>><br>
> >>> Can we detect both of them automatically and add
to exclude list?<br>
> >>><br>
> >>> WBR, Yuri<br>
><br>
>> _______________________________________________<br>
>> squid-users mailing list<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
>> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
>><br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBAgAGBQJUqoe7AAoJENNXIZxhPexGJqoH/2byMvv1s1Qgk5Wh1EwB8ai/
<br>
B6wsw6IvHitGvkrS77OEkEtZYjMsbTEv7XEpZuBvsylIGTr8Zp9amyjcTLOG/A+2
<br>
3L4FwlC2QHj6plf4owN5i3ydKwByZP4qRw97Ydg6rsXM/UpD3ePZl9tWf4TVZDLf
<br>
4bv7EErFYN4tnVjsDEKYWfwfbvJkbbOwt/v1LHTyhyhJiP4Q+bQW3iqGfsgyaMbW
<br>
3frxeuZrjNikH3OC9eqFI+bY41n4IUkz5pKdItqzTCEDAo6NghJJrACeG+jQA2+Q
<br>
3WotAv33ErIe7DiRKgBmSRGbzfe5Cbgd4LVn5BUUbsDboRaVb6NrIu2kwzE03OY=
<br>
=nev9
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>