[squid-users] Issue with SSL_BUMP and Office365 (for one...)

[Alex Rousskov]

On 6/5/20 2:55 AM, J. Dierkse wrote:
>> Here is a sketch for v5. Sorry, I do not remember if v4 is equally
>> capable (but it very well may be):
>>
>> # splice as soon as we detect specialHost
>> ssl_bump splice specialHost
>> # peek to get more info if needed
>> ssl_bump peek all
>> # optional: splice if we never detect specialHost
>> ssl_bump splice all
>>
>> ... where specialHost is an ssl::server_name ACL.
> 
> I tried this configuration, but it doesn't give the desired effect.
> In 4.11 it doesn't seem to splice at all, but bump for some reason (is
> it correct not to refer to any bump steps?)

Bugs notwithstanding, the only reason the above configuration could
result in a bumped connection is if Squid wants to report an error to
the client. To make progress, you need to find out what that error is.

* I would start by examining access.log records after adding
%err_code/%err_detail to your custom logformat.

* If that does not help (we are still working on detailing various
errors better), I would look at cache.log after setting debug_options to
ALL,2 or higher.

* If that does not help, I would share a link to a compressed cache.log
after setting debug_options to ALL,9 and reproducing the problem using a
single transaction (to the extent possible).


> I know these errors have been a hot topic, and from what I can find
> (also in this mailing list) is that it should not block the connection.

I agree that host forgery detection should not block intercepted
connections and CONNECT tunnels (by default). I do not know how close
Squid is to that ideal -- there may be some holes in following that rule
of thumb. Also, I do not know whether your connections are bumped due to
these false positives or some other error. See above for the suggested
next steps.


HTH,

Alex.