[squid-dev] [PATCH] Non-HTTP bypass

[Marcus Kool]

On 12/31/2014 02:31 PM, Alex Rousskov wrote:
> On 12/31/2014 03:33 AM, Marcus Kool wrote:
>> On 12/31/2014 05:54 AM, Alex Rousskov wrote:
>>> What would help is to decide whether we want to focus on
>>>
>>>     A) multiple conditions for establishing a TCP tunnel;
>>>     B) multiple ways to handle an unrecognized protocol error; OR
>>>     C) multiple ways to handle multiple errors.
>>>
>>> IMO, we want (B) or perhaps (C) while leaving (A) as a separate
>>> out-of-scope feature.
>>>
>>> The proposed patch implements (B). To implement (C), the patch needs to
>>> add an ACL type to distinguish an "unrecognized protocol" error from
>>> other errors.
>
>
>>  From an administrators point of view, the admins that want Squid to
>> filter internet access, definitely want (B).  They want (B) to block
>> audio, video, SSH tunnnels, VPNs, chat, file sharing, webdisks and all
>> sorts of applications (but not all!) that use port 443.
>
> Agreed, except this is not limited to port 443. The scope includes
> intercepted port 80 connections and even CONNECT tunnels.

If CONNECT tunnels are in scope, then so are all the applications that use it,
including webdisk, audio, video, SSH etc.

I think it was Amos who said that application builders hould use application-specific
ports, but reality is that all firewalls block those ports by default.
Skype was one of the first applications that worked everywhere, even behind
a corporate firewall and it was done using CONNECT to the web proxy.
And from a security point of view I think that administrators prefer that
applications use CONNECT to the web proxy to have more control and logging
about what traffic is going from a LAN to the internet.

>> Basically
>> this means that admins desire a more fine-grained control about what to
>> do with each tunnel.
>
> There are two different needs here, actually:
>
> 1. A choice of actions (i.e., "what to do") when dealing with an
> unsupported protocol. Currently, there is only one action: Send an HTTP
> error response. The proposed feature adds another action (tunnel) and,
> more importantly, adds a configuration interface to support more actions
> later.

Sending an HTTP error to an application that does not speak HTTP is not
very useful.  Skype, SSH, videoplayers etc. only get confused at best.
Simply closing the tunnel may be better and may result in an end user message
'cannot connect to ...' instead of 'server sends garbage' or 'undefined protocol'.

Marcus

> 2. A way to further classify an unsupported protocol (i.e.,
> "fine-grained control"). I started a new thread on this topic as it is
> not about the proposed bypass feature.
>
>
> Cheers,
>
> Alex.