Re: filtering HTTPS

Henrik Nordström wrote:
> tis 2012-03-13 klockan 19:27 -0300 skrev Marcus Kool:
>>> 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.
>
> non-HTTP traffic do not fit URLs or ICAP either. How would you map an
> SSH session?

Sorry, I know virtually nothing about the internals of Squid so how
to map it... I don't know.

The only thing that I can say at this moment that Squid should give a
filter the opportunity to inspect the content. If for whatever reason
Squid cannot provide the content of a data stream, it should at least
signal the filter that it does a CONNECT to a non-SSL+HTTP address
so that the filter can probe/analyse/decide what to do.

>
>> 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.
>
> ICAP is designed for HTTP and is very message at a time oriented,
> separating request & response seeing them as separate entities.
>
> For HTTP(s) it does support piped operation where the request & response
> is being filtered as it's being forwarded. It's only a matter of the
> ICAP Server starting it's response before the whole request/response
> have been seen.
>
> But I do not think ICAP is suitable for general data stream
> filtering/adaptation. The protocol is simply not designed for it. In a
> data stream filter/adaptation you want to operate on the bidirectional
> datastream as a whole.
>
> Regards
> Henrik
>
>
>
Received on Wed Mar 14 2012 - 12:35:34 MDT