[squid-users] Started testing squid-6.0.0-20210204-r5f37a71ac

[Alex Rousskov]

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 at measurement-factory.com> 
> Sent: Tuesday, February 16, 2021 9:57 PM
> To: Eliezer Croitoru <ngtech1ltd at gmail.com>
> Cc: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] 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 at measurement-factory.com> 
>> Sent: Monday, February 15, 2021 9:03 PM
>> To: Eliezer Croitoru <ngtech1ltd at gmail.com>; squid-users at lists.squid-cache.org
>> Subject: Re: [squid-users] 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 at measurement-factory.com> 
>>> Sent: Thursday, February 11, 2021 7:02 PM
>>> To: Eliezer Croitoru <ngtech1ltd at gmail.com>; squid-users at lists.squid-cache.org
>>> Subject: Re: [squid-users] 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 at measurement-factory.com> 
>>>> Sent: Tuesday, February 9, 2021 11:03 PM
>>>> To: Eliezer Croitoru <ngtech1ltd at gmail.com>;
>>>> squid-users at lists.squid-cache.org
>>>> Subject: Re: [squid-users] 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.
>>>>