Re: [squid-users] Transparent intercept Squid 3.5.20: where VPNs go to die.

2016-08-29 Thread Alex Rousskov
On 08/29/2016 10:43 AM, Stanford Prescott wrote:

> Is there a way to tell Squid that there may be port 443 connections that
> don't use TLS/SSL so that a useful message could be generated other than
> the "connection failed" message the VPN client gives?

Not quite, but we are slowly getting there:

Recent Squids have on_unsupported_protocol feature that is usually
triggered when Squid receives a request using the wrong protocol,
including receiving non-SSL bytes instead of SSL Hello. You can
configure Squid to respond with an error response in that case (in fact,
that is the default behavior).

In theory, you can also configure Squid to customize that error response
using deny_info, but see
http://lists.squid-cache.org/pipermail/squid-users/2016-August/012124.html
 (Ideally, we should support a better way of customize error responses
than denying them and using deny_info to customize denied responses!)

Even if deny_info works, there is currently no way to customize an error
response so that it becomes a non-HTTP response, but that (together with
ACLs/code to detect common non-HTTP protocols) would be a welcomed
feature IMO. Ideally, the admin should be able to tell Squid exactly
what bytes to send to the client (as opaque or opaque with placeholders
data) if needed.


HTH,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] Transparent intercept Squid 3.5.20: where VPNs go to die.

2016-08-29 Thread Stanford Prescott
I have successfully gotten Squid 3.5.20 to filter both HTTP and HTTPS in
transparent intercept mode. With intercept mode, iptables rules redirect
port 80 to squid's http_port 800 and HTTPS port 443 is redirected to
Squid's https_port 801. It all seems to work exactly as it should.

I have recently been trying to integrate a urlfilter using
url_redirect_program with my Squid implementation, and that works very
well, also.

The problem:

One of the useful features of the urlfilter is that it detects proxy
tunnels and blocks them. Not being very proficient in the use of proxy
tunnels and VPNs I wanted to test it out. I setup a VPN client (CyberGhost
VPN) on my Linux client connected to my firewall with the Squid
implementation and could successfully establish a VPN connection *via port
443* when Squid and the URL Filter were disabled. After disconnecting the
VPN and enabling Squid and the urlfilter, attempting to connect using the
VPN over 443 failed to connect.

Now that actually might be a good thing because I am trying to block it
anyway. But the block is an error and not in the manner that is expected.
It is blocked, it seems, because the redirection of port 443 to Squid
causes Squid to barf on the VPN because the VPN, while using port 443 is
not a TLS/SSL encrypted connection and Squid doesn't seem to know what to
do with the connection.

Is there a way to tell Squid that there may be port 443 connections that
don't use TLS/SSL so that a useful message could be generated other than
the "connection failed" message the VPN client gives? There are error
messages in the Squid cache.log about connection attempts failed because of
problems with TLS/SSL and certs.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users