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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
