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
