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
