[squid-users] SSL bump config or possible code issue

[Alex Rousskov]

On 12/08/2016 09:15 AM, Greg Saylor wrote:

> I'm trying to debug a situation where squid 3.4 would return a ERR_ACCESS_DENIED and version 3.5 does not.

I trust you use Squid v3.5.22 or later. Some v3.5 releases have serious
SslBump bugs so the minor version is important.


> I started looking at the source code between 3.4 and 3.5. In 3.5 there is this code in src/client_side_request.cc.
> 
>         if (sslBumpNeeded()) { 
>             // We have to serve an error, so bump the client first.
>             sslBumpNeed(Ssl::bumpClientFirst);
>             // set final error but delay sending until we bump 
...
>         } else  
>             // send the error to the client now


> If I change:
> 
> if (sslBumpNeeded()) {
> 
> to:
> 
> if (sslBumpNeeded() && 0) {
> 
> Then it correctly responds with ERR_ACCESS_DENIED.


Do you enable SslBump features in your Squid?

* If you did not enable SslBump and sslBumpNeeded() returns true, then
this is a Squid bug. If you can reproduce with the latest Squid v3.5 (or
later), please file a bug report.

* If you enabled SslBump, then Squid tries to bump the client connection
to serve the error message to the HTTPS client (because popular browsers
ignore errors delivered as CONNECT responses). I do not recall whether
Squid v3.4 did that, but that is pretty much irrelevant because v3.5
behavior is deliberate (that behavior may need more configuration
options, but that is unrelated to v3.4 anyway). There may be bugs with
that code path, but they are not related to the sslBumpNeeded() result
as such.


> It looks to me as if something is taking precedence over
> calloutContext->error.  But even if it was not, because the request
> is actually being processed it would allow a security hole where an
> attacker could map a private internal network of https services based
> on the time it takes them to respond - even if it allowed the
> connection.

Agreed. If you are using SslBump, then, as the next step, I recommend
ignoring Squid code and clearly demonstrating that Squid forwards a
request that should be denied. A packet trace or Squid's HTTP request
printouts would be helpful for those of us who do not know what exactly
that "socat" command does in your environment, and what Squid does when
processing that traffic.

Alex.