On 2/18/21 5:54 AM, Eliezer Croitoru wrote: > I am waiting for these who want to debug this issue. Understood. If nobody volunteers to do the initial legwork, I would recommend collecting and sharing a transaction log as detailed in my previous response. Alex. > -----Original Message----- > From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, February 16, 2021 9:57 PM > To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx> > Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Started testing squid-6.0.0-20210204-r5f37a71ac > > On 2/16/21 2:40 AM, Eliezer Croitoru wrote: >> Google host means that the host that squid couldn't connect ie : >>>>> connection on conn2195 local=216.58.198.67:443 >>>>> remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1 >>>>> >> >> 216.58.198.67:443 >> >> The issue can be teste against this host.( the above) >> There is an issue with ssl bump and this specific host is a re-producible issue/case/problem. > > Thank you for clarifying that. > > FWIW, in my tests, a v6-based Squid successfully bumps the connection to > (a result of the reverse DNS lookup of) 216.58.198.67 IP address: > >> ... NONE_NONE/200 0 CONNECT dub08s02-in-f3.1e100.net:443 ... >> ... TCP_MISS/404 1960 GET https://dub08s02-in-f3.1e100.net/ ... > > Also, the ERROR message you shared earlier suggests that the problem > happens when accepting a TLS client connection ("failure while accepting > a TLS"), but your summary above says "squid couldn't connect" as if the > problem happens when establishing a TLS connection with the server. > > The information you have provided so far does not tell me what goes > wrong in your tests. Hopefully, somebody will volunteer to reproduce > this and discover the cause of these connection establishment problems. > Alternatively, you can try sharing an ALL,9 cache.log of the isolated > failed transaction[1]. After that, we will probably know how to address > those problems. > > [1] > https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction > > Alex. > > >> -----Original Message----- >> From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >> Sent: Monday, February 15, 2021 9:03 PM >> To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: Started testing squid-6.0.0-20210204-r5f37a71ac >> >> On 2/15/21 6:32 AM, Eliezer Croitoru wrote: >> >>> Where exactly do you see Host Header Forgery in my last email? >> >> Your last email says "google hosts". The previous email from you (in the >> same thread) said "Most of the issues I see are related to Host header >> forgery detection" and then named "google host related issue" to be "the >> main issue". I naturally assumed that you are talking about a set of >> Host forgery related issues with one specific Host forgery detection >> issue being the prevalent/major one. >> >> If my assumption was wrong, then you have not addressed the problem I >> stated in my very first response -- I still do not know what "google >> host related issue" is. The cache.log lines you have posted do not >> answer that question for me. You seem to know what the problem actually >> is, so, if you want answers, perhaps you can detail/explain the problem >> you are asking about. >> >> Alex. >> >> >>> -----Original Message----- >>> From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >>> Sent: Thursday, February 11, 2021 7:02 PM >>> To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx >>> Subject: Re: Started testing squid-6.0.0-20210204-r5f37a71ac >>> >>> On 2/11/21 10:41 AM, Eliezer Croitoru wrote: >>> >>>> The issue that makes it's impossible to surf not to cache. >>>> The >>>>> 2021/02/07 19:46:07 kid1| ERROR: failure while accepting a TLS >>>>> connection on conn2195 local=216.58.198.67:443 >>>>> remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1 >>>>> >>>>> current master transaction: master78 >>>>> >>>>> which is a google host related issue. >>>> >>>> The access to google hosts seems to be the main issue here. >>> >>> How is this different from the host forgery related discussions we >>> recently had? I consider the general "What can we do about host forgery >>> errors?" question answered already. If you disagree with those answers, >>> we can discuss further, but, to make progress, you need to say >>> explicitly which answer you disagree with and why. >>> >>> Alex. >>> >>> >>>> -----Original Message----- >>>> From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >>>> Sent: Tuesday, February 9, 2021 11:03 PM >>>> To: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx>; >>>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>>> Subject: Re: Started testing squid-6.0.0-20210204-r5f37a71ac >>>> >>>> On 2/7/21 12:47 PM, Eliezer Croitoru wrote: >>>>> I move on to testing squid-6.0.0-20210204-r5f37a71ac >>>>> >>>>> Most of the issues I see are related to Host header forgery detection. >>>>> >>>>> I do see that the main issue with TLS is similar to: >>>>> >>>>> 2021/02/07 19:46:07 kid1| ERROR: failure while accepting a TLS >>>>> connection on conn2195 local=216.58.198.67:443 >>>>> remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1 >>>>> >>>>> current master transaction: master78 >>>>> >>>>> which is a google host related issue. >>>> >>>> >>>>> Alex and Amos, >>>>> >>>>> Can the project do something about this? >>>> FWIW, I do not understand what you are asking about -- it is not clear >>>> to me what "this" is in the context of your question. As you know, there >>>> have been several recent discussions about host header forgery detection >>>> problems. It is not clear to me whether you are asking about some >>>> specific new case or want to revisit some specific aspects of those >>>> discussions. >>>> >>>> Alex. >>>> _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
