Re: filtering HTTPS

Tsantilas Christos wrote:
> 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.

Data streams come in parts.
Maybe a filter wants to see the first data chunk of the client, followed
by the first data chunk from the server and followed by the second data chunk
of the client to finally decide: block (close sockets) or say "I am not
interested anymore". So the filter receives all data chunks of the data stream
until it signals the proxy about its decision. For all chunks, when there
is not yet a decision, the filter needs to respond with something like "Continue".

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

I understood that sslBump is necessary for SSL+HTTP. It works fine even
with the simple URL redirector.

> 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 - 14:22:48 MDT