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

[j.dierkse at madeo.nl]

> On 5 Jun 2020, at 15:32, Alex Rousskov <rousskov at measurement-factory.com> wrote:
> 
> 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.
> 

Thanks!

I will start to dig a bit more into what the underlying errors are. I will report back here when I have more info.


Best,


J. Dierkse