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

Mon Jan 5 14:48:24 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wait a minute, gents.

What about ICAP? What I skipped?

05.01.2015 20:38, Douglas Davenport пишет:
> Marcus, not to distract from the very important main points being discussed here but I have to
question your last line:
> "i.e. there is not yet an interface for this type of traffic inspection."
>
> Is that not the whole point of Squid's ICAP interface and HTTPS
bumping? Or do you just mean that ufdbguard doesn't utilize that yet. If
so you might want to consider adding that functionality...
>
>
>
>
> On Mon, Jan 5, 2015 at 9:10 AM, Marcus Kool
<marcus.kool at urlfilterdb.com <mailto:marcus.kool at urlfilterdb.com>> wrote:
>
>
>
>     On 01/05/2015 11:11 AM, Yuri Voinov wrote:
>
>
> And also:
>
> don't forget about bogus homebrew internet-bankings. Which is uses
bogus SSL-certs with bogus GOST realisations. And bogus Java-based
clients. All of them also uses 443 port. And often HTTPS with
> homebrew bogus features.
>
> We don't know, how to bump it.
>
> What about it? Pass-through? Pass-through.
>
> This is clean exclusion.
>
> So don't worry about SSH/Tor. To block them we will be use another
solutions. DPI. And not always technical. Revoke administrative rights
from clients is basics of security, like physical access to
> infrastructure. If they can't install Tor/SSH - why we can worry about
this traffic?
>
> We have (and can solve) two simple problems. HTTP over 443 port. And
SSL Pinning. That's all, folks.
>
>
> >     It is clear what *you* want.
> >     You prefer  Squid + HTTP filter + Cisco/DPI + tcputils + sniffer
+ manual maintenance of ACLs/exclude list
>
>
>
> 05.01.2015 17:51, Marcus Kool пишет:
>
>     Much of the discussion so far  has been about bumping traffic on
port 443,
>
>  > bumping SSL-encapsulated HTTP traffic and not bumping (allowing)
>  > other traffic.  Since port 443 is used for many protocols, it is in
many
>  > cases dangerous to allow non-bumpable traffic: SSH tunnels using
port 443
>  > are common, so are VPNs.  Do you know a security officer who does
not want
>  > to block an SSH tunnel, or an app that can share corporate documents
>  > on public websites?  If there is not more attention to these kinds of
>  > applications that use port 443 to circumvent corporate firewalls,
>  > Squid will be doomed to be used only in environments where the priority
>  > for security is low to non-existent.  Just type "punching holes in
corporate
>  > firewalls" or "ssh tunnel proxy" in Google to see how easy it is to
use an
>  > SSH tunnel.
>
>  > I am the author of ufdbGuard, a filter for Squid and besides filtering
>  > based on URLs, ufdbGuard also probes port 443 to see what kind of
traffic
>  > the server is expecting.  By using probes, ufdbGuard can detect SSH
tunnels,
>  > popular chat protocols, etc. but it is not a 100% guaranteed solution
>  > because ufdbGuard cannot not see the traffic that flows through the
proxy,
>  > i.e. there is not yet an interface for this type of traffic inspection.
>
>  > Marcus
>
>
>  > On 01/05/2015 07:59 AM, Eliezer Croitoru wrote:
>  > Hey Yuri,
>
>  > Indeed there are other *NIX systems and for each and every one of them
>  > there is a solution in need.
>
>  > SSL Pinned destinations cannot be identified automatically since the
>  > are pinned inside a software and the certificate will not show
>  > anything about that.
>  > The basic tests we can do are:
>  > - The host is using ssl or tls or not at all(based on the selective
>  > answer of the service)
>  > -
>  > - If the connection is using tls\ssl then inspect the components of
>  > the certificate(such as rootCA validation against the local machine
>  > certificates DB)
>
>  > Depend on the goal of the certificate validation the decision will be
>  > made to either allow the connection "uninspected" or to "bump" it as
>  > is without any smart identification.
>
>  > If indeed there is a database
>  > sqlite3\mysql\postgres\redis\memcached\others it can be used in the
>  > iptables level.
>  > Also a point in this DB and this cache is that it will be persistent
>  > so what so ever the *NIX system is there is an option once the IP +
>  > port was tagged as non-bump-able it is better be in the FIREWALL level
>  > override better then squid external_acl.
>  > Reason: If the kernel does what it needs to do then squid should not
>  > touch the packets.
>  > It's not always right but it's a point in the issue.
>  > I still do not know how to work with NFQUEUE and I am sure that there
>  > is an option to make a fast decision and if not then let the
>  > connection be BUMPED.
>
>  > I have written a small golang script that can check couple things
>  > about the ssl session at:
>  > http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go
<http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go>
>
>  > Besides this helper there is another script which do couple things in
>  > another level.
>
>  > ##########
>  > If any thing will be decided for squid internals it will be after a
>  > proof of concept that we can implement together.
>  > Can we take this thread to storm and put on the table a proof of
>  > concept logic for ssl inspection\bumping and bypassing?
>
>  > Eliezer
>
>  > On 01/05/2015 10:40 AM, Yuri Voinov wrote:
>  > >>> 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
>
>  >> _______________________________________________
>  >> squid-users mailing list
>  >> squid-users at lists.squid-cache.org
<mailto:squid-users at lists.squid-cache.org>
>  >> http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
>  >>
>  > _______________________________________________
>  > squid-users mailing list
>  > squid-users at lists.squid-cache.org
<mailto:squid-users at lists.squid-cache.org>
>  > http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
>
>
>
>
>         _______________________________________________
>         squid-users mailing list
>         squid-users at lists.squid-cache.org
<mailto:squid-users at lists.squid-cache.org>
>         http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
>
>     _______________________________________________
>     squid-users mailing list
>     squid-users at lists.squid-cache.org
<mailto:squid-users at lists.squid-cache.org>
>     http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUqqQ3AAoJENNXIZxhPexGfpUIAISbpvePCM5J4Bo+M7V2tnp5
V62ELnU6ScjRtHgdOt3ywkb54fuXpqoGEG+jqbNhzEtc4K3P3Ek3sHfximEJ04Ut
EtH3K2WGqvmBGyogK0PI0pNp9oBwpEgDPKPmHaPj5qoCHaSmNaJkD6jmQ24T6B6R
yjnxu5gdUKnf+MF2Tnuui9QJtxy/Gsgn1Eef0DOr7B7fxiqFV6+SR+G9DjHYWJNV
Jx3f7iG1uJsuUCZQOI7i8NhaRYaDuMaxNaMVcniiKY6NEMAFSetxsvlURqv2gLKN
DNdtvXiLpbydkK5LaFQNi+meMILcEKjXPZ/aK9WVehR2lIy2hzWC6PbSVdN/eC8=
=BWP9
-----END PGP SIGNATURE-----

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