Re: filtering HTTPS

On 03/14/2012 12:27 AM, Marcus Kool wrote:
>
> 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".

There is the ICAP preview transaction. The proxy send headers and a part
of the data (eg the first 1024 bytes) and the ICAP server can respond
with "100 Continue" to tell to the proxy "continue with data stream", or
"204 Allow" to tell to the proxy that "I am not interested any more".

> On 03/14/2012 01:33 AM, Amos Jeffries wrote:
>> It does. http://www.squid-cache.org/Doc/config/icap_206_enable/

The 206 responses are similar to 204 responses (inside or outside
preview) but also allow modifying the headers or the head of the data.

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

You can not filter SSL streams (HTTPS) in any way. The only way is
through a mechanism like sslbump.

Using ICAP you can filter streams and you can implement filter pipes, IF
the protocol is HTTP like, it has HTTP like headers and HTTP like body
data. But also this is requires that the filter can operate on data
pipes (it can operate on a window of the data)

>
>> Regards
>> Henrik
>
Received on Wed Mar 14 2012 - 09:25:49 MDT