[squid-users] sslBump adventures in enterprise production environment

[Eugene M. Zheganin]

Hi.

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

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
is straightforward:

===Cut===
acl foo dst 192.168.0.1
acl bar dst 192.168.0.2

sslBump bump foo
sslBump splice bar
===Cut===

It's one dst we bump and the other we splice.

Can you describe a situation when I need to peek or stare ?

Thanks.
Eugene.