[squid-users] sslBump adventures in enterprise production environment
Eugene M. Zheganin
emz at norma.perm.ru
Mon Dec 28 18:47:00 UTC 2015
On 16.11.2015 0:39, Alex Rousskov wrote:
> On 11/15/2015 12:03 PM, Eugene M. Zheganin wrote:
>> It's not even a HTTPS, its a tunneled HTTP CONNECT. But
>> squid for some reason thinks there shoudl be a HTTPS inside.
> 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
Thanks a lot for this explicit explanation.
I managed to solve the problem with ICQ using the information above, no
matter what port, 5190 or 443 it's tunneled into. Even
"on_unsupported_protocol" isn't needed, so the whole thing works just
fine on 3.5.x. In case someone will need this too, I decided to post my
# Minimum ICQ configuration,
# works for QIP 2012 and squid/ssl_bump, login.icq.com port should be
either 443 or 5190
acl icq dstdomain login.icq.com
acl icqport port 443
acl icqport port 5190
# mail.ru network where ICQ servers reside
acl icqip dst 18.104.22.168/20
acl step1 at_step SslBump1
# http_access part is needed; not shown here since it's ordinary, for
qip or web clients to work
# this should be somewhere near the top of the ssl_bump directives piece
ssl_bump splice step1 icq
ssl_bump splice step1 icqip icqport
[...other ssl_bump directives...]
More information about the squid-users