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

[Alex Rousskov]

On 01/02/2015 09:16 AM, Marcus Kool wrote:
> 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.

Yes, of course. The receiving Squid port and current connection state
affects what protocol Squid expects to find/parse, whether Squid may
perform (or has performed) bumping, etc., but all those decisions and
actions happen before and/or after the new feature kicks in. The
detection of an unsupported protocol and computation of the
corresponding tunnel/respond decision is what we focus on here.


> 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.

Yes, the "each application has a dedicated port" idea[l] is too far from
reality to matter.


>>> 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'.


I may have already mentioned that "terminate" is another candidate
action. For now, it is possible to emulate that action in some
deployments by using custom "TCP_RESET" error bodies, but that hack is
too rigid: It does not discriminate the error context/environment. That
is what ACLs in the new feature are meant to do.

Whether it is better to simply terminate the connection or send some
diagnostic text to the user client should be up to the admin to decide.
Different deployment environments will benefit from different actions.
The proposed feature builds the initial framework for those decisions.


Cheers,

Alex.