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

Alex Rousskov rousskov at measurement-factory.com
Wed Dec 31 16:31:05 UTC 2014


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.


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

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.



More information about the squid-dev mailing list