[squid-users] sslBump adventures in enterprise production environment
Eugene M. Zheganin
emz at norma.perm.ru
Mon Nov 16 06:13:21 UTC 2015
On 16.11.2015 00:39, Alex Rousskov wrote:
> Hello Eugene,
> Squid currently supports two kinds of CONNECT tunnels:
> 1. A regular opaque tunnel, as intended by HTTP specifications.
> 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic.
> Opaque tunnels are the default. Optional SslBump-related features allow
> the admin to designate admin-selected CONNECT tunnels for HTTPS
> inspections (of various depth). This distinction explains why and when
> Squid expects "HTTPS inside".
> There is currently no decent support for inspecting CONNECT tunnels
> other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels.
> Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel
> into an opaque tunnel before inspection starts.
> The recently added on_unsupported_protocol directive can automatically
> convert being-inspected non-HTTPS tunnels into opaque ones in some
> common cases, but it needs more work to cover more cases.
> AFAICT, you assume that "splicing" turns off all tunnel inspection. This
> is correct for step1 (as I mentioned above). This is not correct for
> other steps because they happen after some inspection already took
> place. Inspection errors that on_unsupported_protocol cannot yet handle,
> may result in connection termination and other problems.
> If Squid behavior contradicts some of the above rules, it is probably a
> bug we should fix. Otherwise, it is likely to be a missing feature.
> Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to
> figure out whether those connections are inspected (i.e., go beyond
> SslBump step1). If they are inspected, then this is not a Squid bug but
> a misconfiguration (unless the ACL code itself is buggy!). If they are
> not inspected, then it is probably a Squid bug. I do not have enough
> information to distinguish between those cases, but I hope that others
> on the mailing list can guide you towards a resolution given the above
Seems like the lack of understanding is my main problem. I read
Peek/Splice article in wiki on an on, but I just cannot catch it:
- are the sslBump directives evaluated in order and does the order
matter (I assume it does) ?
- (the most difficult thing to understand) I just cannot understand the
"step1" approach. I can understand splice/bump thing - it's like we
splice or we bump. I cannot understand other stepX-related actions, what
they do and when do I need'em (and when I do not).
- I cannot understand what is the relation between http_access and
sslBump, and I assume there is one. When I first discovered sslBump I
thought I will be able to block HTTP objects inside HTTPS session - like
pictures, or particular scripts, or particular MIME types, and it seems
like I was able to do that, But now things became complicated in my
head, I can't even reproduce my past results, I'm starting to think that
this was an illusion of success.
Could you clarify things a bit ? For example this number of directives
acl foo dst 192.168.0.1
acl bar dst 192.168.0.2
sslBump bump foo
sslBump splice bar
It's one dst we bump and the other we splice.
Can you describe a situation when I need to peek or stare ?
More information about the squid-users