Re: filtering HTTPS

Henrik Nordström wrote:
> tis 2012-03-13 klockan 12:12 -0300 skrev Marcus Kool:
>
>> Where does the filtering gets involved? Also NoneSSL sites (aka tunnelmode) need to be filtered/blocked and/or scanned for virusses.
>
> Squid is not the tool for filtering non-http(s) traffic beyond requested
> hostname.

I agree. Squid is not. This task is for the URL rewritors and ICAP servers.
One way or another, Squid should offer all data that passes through it (1)
to a filter. I like ICAP, but ICAP is designed for HTTP and not HTTPS
and certainly not for non-HTTP, non-HTTPS data streams.

(1) a virusscanner and a URL filter do not need the *whole* data stream.
The first max-64K upload and the first max-64K download is most likely
sufficient to determine what to do, pass or block. The protocol should
have a feature that the filter is able to tell to Squid "Continue with
this data stream, but I am not interested in it any more".

> But it would be trivial to extend tunnel mode with a filter pipe, both
> in normal tunnel mode and SSL relay mode (decrypted & encrypted,
> tunneling between two SSL connections).

A filter pipe is interesting. A question is on how to implement it.
ICAP has no support for it and in my opinion ICAP should be extended
to support this. I know it is a long way to extend existing protocols
but maybe it works by just doing it and making it a de facto standard.

The question is what works best:
A) use extended ICAP for regular HTTP(S) and data streams
B) use ICAP for regular HTTP(S) and a new data stream protocol for data streams

> Regards
> Henrik
Received on Tue Mar 13 2012 - 22:27:09 MDT