Re: [RFC] Peek and Splice

On 02/01/2013 01:48 PM, Alex Rousskov wrote:
> On 02/01/2013 06:47 AM, Marcus Kool wrote:
>
>> This Peek&Splice feature will make ssl_bump a useful feature since
>> without Peek&Splice ssl_bump aborts all non-SSL CONNECTS from Skype
>> and other applications, so the user community will certainly welcome this.
>
> Well, SslBump is already useful in environments where non-SSL CONNECTs
> are either prohibited or can be detected and bypassed using CONNECT or
> TCP-level information. Peek and Splice will allow bypass of non-SSL
> tunnels without building complicated white lists.
>
> While not in this project scope, Peek and Splice would probably make it
> possible (with some additional work) to allow Squid to detect and block
> non-SSL tunnels without bumping SSL tunnels. That could be useful in
> environments where HTTPS is allowed (and does not need to be bumped) but
> other tunnels are prohibited.

Yes, I think it is useful to have an option
    allowed_protocols_for_connect: any|ssl

>
>> Currently Squid only sends to the ICAP server a
>> REQMOD CONNECT www.example.com:443 (without content)
>> and there is never a RESPMOD.
>> I, as author of ufdbGuard and the (yet unpublished) new ICAP content
>> filter,
>> would welcome very much if the data of the peeks (client and server)
>> is encapsulated into ICAP requests for the obvious purpose of
>> content filtering.
>
> Squid already sends bumped (i.e., decrypted) HTTP messages to ICAP and
> eCAP. If that does not happen in your SslBump tests, it is a bug or
> misconfiguration. Squid cannot send encrypted HTTP messages to ICAP or
> eCAP -- you must use SslBump if you want to filter encrypted traffic.
> There is no way around that.

Yes, correct. I mixed the behaviour of Squid with sslbump (decrypted
messages go to the ICAP server) and Squid without sslbump (ICAP server
only receives a REQMOD).

> Or are you thinking about sending SSL Hello messages to ICAP and eCAP
> services? If Peek and Splice succeeds, that will be technically possible
> as well, but will require more work and would be a separate project.

I was thinking about this: when Squid peeks at the data and finds that it
is non-SSL, send it to the ICAP server to ask its opinion.
This is obviously more work, but also extremely useful, since a
content filter is only useful if it is able to inspect _all_ content,
and consequently the feature of Squid to connect to content filters
is only useful if Squid sends _all_ data to the content filter for analysis.

Perhaps needless to say: virusses like to communicate in non-standard
ways to Squid would be considered much more secure if it sends _all_ data
to an ICAP server for analysis.

Marcus
Received on Fri Feb 01 2013 - 16:09:06 MST