[squid-users] sslBump adventures in enterprise production environment
rousskov at measurement-factory.com
Mon Nov 16 18:12:12 UTC 2015
On 11/15/2015 11:13 PM, Eugene M. Zheganin wrote:
> On 16.11.2015 00:39, Alex Rousskov wrote:
>> 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".
> 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) ?
Yes and yes. This is described in squid.conf.documented IIRC.
> - (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).
The wiki describes what each step and each action does. I understand
that those descriptions may not be sufficient. Better documentation is
welcomed, and you are encouraged to ask specific questions to provide
that "better documentation" to yourself and others. You are in a better
position to improve documentation than I am!
> - I cannot understand what is the relation between http_access and
> sslBump, and I assume there is one.
This is poorly documented indeed. For some additional info, see Squid
bug 4340 summary: http://bugs.squid-cache.org/show_bug.cgi?id=4340
> 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,
Sure, you can block messages inside a bumped inspected tunnel. Once the
tunnel is bumped (not spliced!), it works almost like a regular HTTP
message stream (but there are exceptions like authentication and peer
Most difficulties are related to blocking tunnelling attempts
themselves. In other words, blocking CONNECT messages (at various
bumping stages before the tunnel is bumped).
> For example this number of directives is straightforward:
> 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.
The above configuration is not as "straightforward" as you might think:
* If you are dealing with real CONNECT requests (not intercepted
tunnels), a real CONNECT request may be for a host name and Squid will
need to look up the IP address. This may affect dst matching.
* You did not tell Squid what to do when neither dst matches. There were
bugs in this area. The latest Squids should splice (but if you add more
ssl_bump rules, they may affect the default action). IIRC, this is
described in squid.conf.documented.
* Bumping (even at step1) requires SSL/TLS validations of various kinds.
Those validations may lead to errors.
* Bumping at step1 may be subject to the following Squid bug:
> Can you describe a situation when I need to peek or stare?
You need to peek or stare if you need SSL/TLS handshake information to
make a final bump/splice/terminate/block decision. For example,
* Your ACLs need host names, not IP addresses. Even in a forwarding
environment (i.e., real CONNECT requests), host names may not be
available without peeking or staring (or reverse DNS lookups, but those
are rarely reliable).
* Your ACLs need origin server certificate details.
* You do not want to splice connections to origin servers that have
revoked SSL certificates.
More information about the squid-users