[squid-users] Squid "bumping" traffic despite using "splice" directive

[Tom Mowbray]

Thanks for your response.  I don't see anything strange in the access log,
just the initial CONNECT request, but nothing follows because of the error
at the client.  We have squid set to "deny all" on certificate error.

While your suggestions would surely solve the problem, they don't work for
our deployment, as we only want to allow certain sites, so splicing all
will not suffice.  What is strange is that there are no "stare" or "bump"
rules present, yet that appears to be what is happening.

I'll continue to monitor logs and see if I can provide any additional info.

For what it's worth, this is Squid 3.5.11 running on Debian.


---------------------------------
Tom Mowbray
*tmowbray at dalabs.com* <tmowbray at dalabs.com>



*703-829-6694[image: http://www.dalabs.com] <http://www.dalabs.com>*

On Thu, Nov 12, 2015 at 2:12 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 11/12/2015 11:31 AM, Tom Mowbray wrote:
> > We're seeing some strange behavior where certain sites, especially those
> > hosted by Google, including youtube.com <http://youtube.com>, where the
> > HTTPS traffic is being "bumped" and users are getting certificate errors
> > with our self-signed certificate and CA appearing in the certificate
> > details.
>
> Can you tell what Squid is sending on some of those bumped connections?
> Could it be an error message? What does access.log say?
>
>
> > What is strange is that we have the squid.conf set to either "splice" or
> > "terminate" all HTTPS traffic.  There is NO traffic that is supposed to
> > be bumped at all (because we are not able to load our CA cert on all
> > client machines).
> >
> > Here is the significant portion of our squid.conf:
> >
> > acl sslallow ssl::server_name "/path/to/file"
> > ssl_bump peek all
> > ssl_bump splice sslallow
> > ssl_bump terminate all
> >
> > Most of the sites in acl sslallow work as expected...but some sites come
> > back with a certificate error as described above, suggesting that they
> > were "bumped" using our mimicked certificate.  This behavior also isn't
> > 100% reproducible...sometimes it works as expected, though it usually
> > does not.
>
>
> Do you tell Squid to splice on all SSL validation errors and when seeing
> non-SSL traffic on expecting-SSL connections? If yes, then this is most
> likely a Squid bug. Otherwise, perhaps Squid is trying to inform users
> of an error? Triage is needed to understand why Squid is bumping.
>
> There is also a possibly related bug 4321, but it should not affect
> steps 2 and 3 where you terminate connections:
> http://bugs.squid-cache.org/show_bug.cgi?id=4321
>
>
> > Another note:  Seems to happen mainly on mobile browsers and on Chrome
> > browser running on Google Chromebooks.
> >
> > Is there something I'm missing?  Is there a way to ensure that NO sites
> > are being bumped at all?
>
> Yes, there are (or should be) three ways:
>
> 1. Do not use SslBump at all.
>
> 2. Use "ssl_bump splice all" rule and no other ssl_bump rule.
>
> 3. Do not use any "ssl_bump bump" and "ssl_bump stare" rules while
> allowing all SSL errors and non-SSL traffic.
>
> #1 is known to work. Others may or may not work, depending on your Squid
> version, yet-unknown Squid bugs, and other specifics.
>
>
> >  (For our deployment, we'd rather terminate
> > than bump if splicing isn't possible).
>
> Your ssl_bump rules reflect your intent. However, when you use "ssl_bump
> peek all", Squid has to validate SSL clients and servers (to various
> degrees). Other Squid directives tell Squid what to do when that
> validation fails. The ones I remember are on_unsupported_protocol and
> sslproxy_cert_error. Do you configure those directives to ignore all
> errors (and, hence, let users deal with them, including abusing them for
> tunnelling anything through your Squid)?
>
>
> HTH,
>
> Alex.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151112/5f6099ff/attachment-0001.html>