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

Marcus Kool marcus.kool at urlfilterdb.com
Wed Dec 31 10:33:47 UTC 2014



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.  Basically
this means that admins desire a more fine-grained control about what to
do with each tunnel.

The current functionality of filtering is divided between Squid itself and
3rd party software (ICAP daemons and URL redirectors).
I plea for an interface where an external helper can decide what to do
with an unknown protocol inside a tunnel because it is much more flexible
than using ACLs and extending Squid with detection of (many) protocols.

A while back when we discussed the older sslBump not being able to cope
with Skype I suggested to use ICAP so that the ICAP daemon receives a
REQMOD/RESPMOD message with CONNECT and intercepted content, which also is
a valid option for me.

I wish to all a Blessful and Happy New Year!
Marcus

>
[...]
>
>
> Thank you,
>
> Alex.
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


More information about the squid-dev mailing list