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

[Alex Rousskov]

On 12/08/2016 11:42 AM, Greg Saylor wrote:
>> On Dec 8, 2016, at 10:41 AM, Alex Rousskov wrote:
>> 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.

>> Squid [v3.5] tries to bump the client connection
>> to serve the error message to the HTTPS client.

> Regretfully, I have not been able to figure this out. I think its
> more around how the http_access rule result is being squirreled away
> and not being checked before proceeding with the SSL Bump.  Or
> perhaps in more 3.5.22 terms: its not being consulted when deciding
> how to respond to the client request?  Maybe its just not taking
> precedence?

Such a bug is somewhat unlikely but any bug is possible. More
information is needed to confirm or deny the bug itself (and one of your
explanations why it exists).


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

> It this what you mean?

Sorry, that was not it. That quoted v3.5 debugging log does not appear
to have [enough] HTTP information. It is mostly about your Squid talking
to your ICAP service. The v3.4 log was better, but I do not really care
much about v3.4.

Here is what I meant:

* Packet trace is a binary file in libpcap format. Usually produced by
tools like tcpdump or Wireshark. We need traffic from/to Squid (two TCP
connections, four directions). Some of that traffic may be encrypted.
This option works well, at least as a starting point, if Squid forwards
the CONNECT request (or an intercepted SSL connection) that it should
deny because those parts are not usually encrypted.

* Squid's HTTP request printouts can be collected by setting
debug_options to ALL,2 and repeating your test. Please limit the
collection to one failing transaction if possible and attach your logs
(or post a link to them).

Whichever approach you use, please do not forget to identify which
packets/requests were incorrectly forwarded and which "http_access deny"
rules they [should have] matched. In other words, you are essentially
claiming that there is a bug. You may be right! Please provide enough
information to support/illustrate your claim so that we can reproduce
and fix the bug if needed.


HTH,

Alex.