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

Wed Dec 31 12:09:07 UTC 2014

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

Also, finally, gents.

Google Drive application uses network:

# Google Drive
74.125.201.0/24

in my region. ;)

So to bypass bump you must specify this network as dst with no bumping.

WBR, Yuri

31.12.2014 18:00, squid-users-request at lists.squid-cache.org пишет:
> Send squid-users mailing list submissions to
>     squid-users at lists.squid-cache.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>     http://lists.squid-cache.org/listinfo/squid-users
> or, via email, send a message with subject or body 'help' to
>     squid-users-request at lists.squid-cache.org
>
> You can reach the person managing the list at
>     squid-users-owner at lists.squid-cache.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of squid-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Squid Deployment Questions (Amos Jeffries)
>    2. Re: Squid 3 SSL bump: Google drive application could not
>       connect (James Harper)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 31 Dec 2014 22:55:18 +1300
> From: Amos Jeffries <squid3 at treenet.co.nz>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Squid Deployment Questions
> Message-ID: <54A3C806.4010405 at treenet.co.nz>
> Content-Type: text/plain; charset=utf-8
>
> On 31/12/2014 6:59 p.m., Evan Blackstone wrote:
> > Hey all, Wondering if I could get some advice on potentially
> > setting up a Squid forward proxy on my network. I'm not a Linux
> > novice by any means, but I'm not experienced in server
> > administration, log review, etc.
>
> > We're needing to deploy a simple non-caching, non-peering forward
> > proxy to integrate with an ICAP server for web filtering. My plan
> > is pretty basic...here's my network config:
>
> > Internet --> Cisco ASA --> DMZ --> Internal LAN
>
> > I've received conflicting advice on whether or not there's any
> > advantage to putting a forward proxy on the DMZ vs. internal LAN.
> > In any case, 'm wanting to deploy an explicit proxy with a single
> > NIC. Workstations will use a PAC file, etc. to point to the proxy.
>
> > If the server is on the DMZ, I'd allow 80/443 from the internal LAN
> > to the DMZ, then allow 80/443 from the proxy to outside. I'd also
> > be allowing the proxy to internal LAN for ICAP, syslog, and
> > possibly NTP. The proxy would have a single interface...although it
> > would NAT to outside for internet access, there would be no ports
> > open on the outside interface.
>
> Like Eliezer mentioned if ICAP services are in the LAN place the proxy
> there. Placing the proxy in the DMZ if ICAP services are in the LAN
> means the traffic has to flow across the DMZ<->LAN pathways three
> times - limiting your traffic to 1/3 of line speed on the slowest NIC
> along the way.
>
> Similarly using a single NIC machine means the HTTP traffic through
> the proxy is already limited to 1.2 the speed of that NIC. If it's not
> a Gbit NIC then using two NIC (for separate inbound and outbound
> flows) will allow Squid to run at capacity - which is somewhat over
> 50Mbps these days and increasing a little each release.
>
>
>
> > Based on some testing I've done, my squid.conf would be pretty
> > basic...
>
> > http_access allow internalnetwork cache deny internalnetwork
> > always_direct allow internalnetwork http_access deny all etc.
>
>
> No need for always_direct. Nor for "cache deny internalnetwork".
>
> You could use "cache deny all" to prevent all HTTP caching but a small
> amount of memory-only cache is good for improving responses to the
> topmost popular URLs. Squid has a default 256MB of memory cache to
> store approx 10K objects (cache_mem directive).
>
>
> > My questions are:
>
> > Does it sound like I'm on the right track here? Would the above
> > described configuration be safe? I've read that Squid should listen
> > only on an internal interface? What about when the server only has
> > one?
>
> Use the default squid.conf as a basis and extend as necessary. It has
> the basic security measures that are important. For a quick start you
> only need to ensure *localnet* ACL is defined with your LAN IP ranges
> and you are good to go as a forward proxy.
>
>
> Internal/external interface makes no difference when there is only one
> NIC.
>
> The default config is safe enough to reject traffic from external
> sources (non-localnet), but you can be extra sure with either a
> firewall block in the routers preventing non-LAN connections inbound
> to the proxy machine.
>
>
>
> > What level of risk would I be assuming (regular patching included)?
> > Given that I'm relatively new to monitoring Linux servers for
> > security, etc., is this a bad idea? I'm not really sure what to be
> > looking for log-wise in terms of compromise. I have edge devices
> > and monitoring on the perimeter, but I don't really know what to
> > look for on the server itself...
>
> Squid is one of (if not The) most hardened proxies available. It can
> basically only be compromised in two ways:
> 1) corruption of cached objects - you dont have any on disk, and
> avoiding the refresh_pattern override/ignores removes the risk of
> memory objects corruption.
>
> 2) infection of the binaries that make up Squid - this is not
> detectable from within Squid anyway. A system AV scanner (or regular
> update schedule) is required for that.
>
> Squid does crash in a numer of ways, but that is a fail-closed DoS
> type event rather than compromise.
>
> * You should monitor cache.log for anything that mentions "assertion"
> or "FATAL". These are Squid bugs and self-DoS vulnerability. We are
> always interested in finding out how these happen and fixing.
>
> * access.log monitoring is a possibility. One can usually find web
> exploits being attempted on *other* services in a Squid access.log, so
> monitoring it like one woud la web server log for suspicious URL
> requests can be useful to proactively identify compromised clients.
>
>
> The Safe_ports and SSL_ports ACLs in the default config map out blocks
> on the ports with known security issues.
>
> You may have clients with web apps needing special ports accessible
> via CONNECT. Take the usual due-diligence there as if you were opening
> a firewall port for unrestricted use, then if you wish add the port
> number to SSL_ports ACL (Safe_ports should already be open for 1024 or
> larger port numbers).
>
>
> You can enable the to_localhost rules which are commented out by
> default to protect against clients accessing services on the Squid
> machine itself (if any exist accessible over localhost interface).
> Though on a dedicated proxy the SSL_Ports rule should already be
> taking care of that.
>
>
>
> > Am I approaching this the wrong way? Should I be looking at putting
> > it on the inside LAN? Would such an approach leave my network
> > vulnerable should the Squid box get owned?
>
>
> Since the purpose of a proxy is to be reachable from LAN clients the
> security impact on Squid itself is no different in either position.
>
> The security balance is betweeen whether the rest of the machine
> access methods (including the ICAP servers security "footprint") are
> more/worse secure in either position vs the traffic costs mentioned above.
>
> NP: ICAP servers and particularly the unencrypted TCP connections to
> them are the weakest point, since they have the ability to alter the
> HTTP traffic contents in arbitrary ways. Explicitly not touching the
> traffic content is one of the security hardening aspects of Squid.
>
> Amos
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 31 Dec 2014 11:11:36 +0000
> From: James Harper <james at ejbdigital.com.au>
> To: "squid-users at lists.squid-cache.org"
>     <squid-users at lists.squid-cache.org>
> Subject: Re: [squid-users] Squid 3 SSL bump: Google drive application
>     could not connect
> Message-ID:
>    
<HKNPR04MB1933D74D5F5A53D56ED20C8E85F0 at HKNPR04MB193.apcprd04.prod.outlook.com>
>    
> Content-Type: text/plain; charset="utf-8"
>
>>
>> Probably non-HTTPS protocol being used.
>>
>> As bumping gets more popular we are hearing about a number of services
>> abusing port 443 for non-HTTPS protocols on the false assumption that
>> the TLS layer goes all the way to the origin server without
>> inspection. That has never been a true assumption, CDN frontends have
>> always decrypted.
>>
>
> I've mentioned it before, and it's been pointed out that it probably
doesn't scale, but I wrote a callout helper for this reason and for
better logging.
>
> Basically:
>
> external_acl_type cert_callout concurrency=20 %DST %PORT
/usr/local/squid/libexec/ext_cert_callout_acl
> acl is_ssl external cert_callout IS_SSL
> ssl_bump bump is_ssl
> ssl_bump splice all
>
> The helper connects to the IP:port and tries to obtain the
certificate, and then caches the result (in an sqlite database). If it
can't do so within a fairly short time it returns failure (but keeps
trying a bit longer and caches it for next time). Alternatively if the
IP used to be SSL but is now timing out it returns the previously cached
value. Negative results are cached for an increasing amount of time each
time it fails, on the basis that it probably isn't SSL.
>
> So it's somewhat optimistic - on a slow link or for a slow server a
given IP:port might be spliced the first time when it should be bumped,
but it will learn fairly quickly. And for non-SSL connections that
appear to just hang in response to the request there will be an
additional delay the first time. But otherwise it learns about the
target without requiring admin intervention.
>
> It also returns the name of the cert so it can be logged instead of
the IP (for transparent connections), although that isn't ideal as the
same IP might be used for many services (google/youtube/etc)
>
> I can post it if anyone is interested, although it would require a bit
of work to be completely useful.
>
> James
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ------------------------------
>
> End of squid-users Digest, Vol 4, Issue 75
> ******************************************

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

iQEcBAEBAgAGBQJUo+djAAoJENNXIZxhPexGcEAH/Ap3Vx/czpznQaAAtKoeHK/k
6NXQTJVYxC5FkSV9S4UXGjp+DcWd4bIsIPC0oZ0ZJ7W67d98qC0lP3ciC6rBwPnB
cV9pzA2ewL73dWQJOwd1rtX44ZVvAgA9uDlg0zW7ZDrrefw1ACxgPvD2Ta2EHNsI
QD8FwMSA7I5IGc2jgYeL0uILnWX64BuTUw/r1zIbm6uMaRERjxWOujNGNgu6ToRL
GKOwdxbZIDGBKYo8LmYG1gv5urvVVtZ2ghpZN9iyFrdSmpBNU9wyPc/OssowY0jX
5Qy9qQD5xWlYpsslivS90WzXdgMpd+n0livRpfIXUStTu6r3juTt34awAG9MzF4=
=QCIn
-----END PGP SIGNATURE-----

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