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.
