[squid-users] Proposal for deny_info

[Amos Jeffries]

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

On 10/11/2014 3:35 a.m., Alejandro Martinez wrote:
> Hi all,
> 
> I'm trying to setup deny_info for denied sites using CONNECT
> method. This is something that doesn't work 100% depending on
> browser, etc.
> 
> Could be possible to change the 30X:http://x.x.x.x/deny.html to
> something based in DNS replies ?
> 
> Squid uses its own directive "dns_nameserver" to configure which
> name server is going to use.

It only has that behaviour if you restrict the list to a single NS entry.

dns_nameserver overrides and replaces all the OS /etc/resolv.conf
settings. It is meant to contain a *set* of DNS servers to select from
("no less than 2, no more than 7" is the BCP standard guideline).

> 
> I was thinking on something like this
> 
> dns_nameserver_deny 172.16.1.1  <- IP of dnsmasq server acl
> deniedsites dstdomain "/list/of/denied/domains" (.youtube.com , . 
> facebook.com ) http_access deny deniedsites
> 
> but instead of
> 
> deny_info deniedsites 307:http://172.16.1.1/deny.html
> 
> something like this
> 
> deny_dns_info deniedsites 172.16.1.1
> 
> and 172.16.1.1 is going to resolv:
> 
> 172.16.1.1 youtube.com facebook.com, etc
> 
> It is possible ?

Sounds horribly complicated and confusing. If you are willing to put
on the coding time almost anything is "possible". Whether it works or
not is a different question.

With Squid-3.2 or later you can use %o in the deny_info. That gets
filled in with the message= value received back from external ACL
helper. You should experiment with that first.

But remember what it comes down to is how the individual browser
handles non-200 responses to a CONNECT request. Simply tweaking the
Content-Location header will not affect that in any significant way
unless it is *already* acting on that header.

> 
> based on destination domain, the IP to return, so if I ask for
> facebook.com I'll get 172.16.1.1 and the certificate warning
> appears, but the error (Denied Site) too.
> 

If deny_info is used on the CONNECT there should not be a certificate
warning at all. Because TLS is never involved. Any of the HTTPS
traffic, being "inside the tunnel" at that point becomes just so many
garbage bytes dropped on the floor when the TCP connection is
necessarily closed.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUX59OAAoJELJo5wb/XPRjSRQIAJF4nE93Wyao6vxYCbXactsZ
oyAE+oiMLiWmocqSN4HnYQH8ykSf5BTYw/FlUsg/LQdhAeiM//UHIig6mN+j2eFx
SkMwTHNc5XkmR0muYP2SfltkQHH3/ZvODZH8W0M4Xv3f9bePqYLwm15N24gmX2GI
EdTeM2P/HEHzOiaWLZ7iDxB3ePcAPlPkScgzO92Jrn1lCfenxy7mxk/h0R6AHwtB
GXGcBhJPtLl/MyBlm2l2fCm6nUWrsKd80p36UMT5eqjZK8AQspZ7o7uDz82P5gnc
Za3dMwnao14LUu7U/ibmzckIn+mecEDpOcgHcktzPnnFBYGnCMUH/2/0GDKd+Sk=
=TKGa
-----END PGP SIGNATURE-----