Re: [RFC] Peek and Splice

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.

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

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.

Thank you,

Alex.
Received on Fri Feb 01 2013 - 15:48:33 MST