[squid-users] squid 7.1 , url_rewrite_program does not work

Dmitry Melekhov dm at belkam.com
Thu Oct 23 05:56:35 UTC 2025


22.10.2025 18:27, Alex Rousskov пишет:
> On 2025-10-22 00:31, Dmitry Melekhov wrote:
>> 22.10.2025 08:17, Amos Jeffries пишет:
>>> On 21/10/2025 18:59, Dmitry Melekhov wrote:
>>>> 21.10.2025 09:20, Amos Jeffries пишет:
>>>>> On 21/10/2025 15:01, Dmitry Melekhov wrote:
>>>>>>
>>>>>> There is third way- revert change, which breaks rewrites,
>>>>>>
>>>>>> this is what I did.
>>>>>
>>>>>
>>>>> Sending all "blocked" visitors to whatever server whose DNS name 
>>>>> starts with "http." is not a fix. 
>>>>
>>>> If browser expects https and gets http it results in error, not in 
>>>> breach.
>>>
>>>
>>> Any server could easily respond with HTTPS on port 80 - especially 
>>> since the domain "http" is rare and likely crafted to exist by an 
>>> attacker.
>>>
>>
>> Sorry, I don't see any real problem here, otherwise all squids before 
>> 7 are affected.
>>
>>>
>>>>
>>>>> It is breaking things in worse ways that are not visible to you.
>>>>>
>>>>> All it takes is for Squid to find it has a record for domain 
>>>>> "http.*" and all your so-called blocked visitors will be hijacked 
>>>>> by that server. Silently.
>>>>>
>>>>>
>>>> I can't understand which server are you talking about.
>>>>
>>>
>>> Any server where Squid resolves the http.* domain name to point at.
>>>
>>>
>>>>
>>>>> The officially patched Squid is rejecting the CONNECT tunnel (as 
>>>>> you want) and also telling you the helper needs fixing. If the 
>>>>> error message is annoying, do one of the fixes I mentioned earlier.
>>>>>
>>>>
>>>> No, squid passes traffic. This is problem. Errors messages is not a 
>>>> problem.
>>>>
>>>
>>> Ah, there is the missing piece. Thank you for correcting me.
>>>
>>>
>>>
>> I think this should be corrected, but this is feature now.
>>
>> Very strange, imho.
>
> Nothing is set in stone here! If you can suggest a specific 
> improvement, please do so. Squid should not go back to silently 
> generating malformed CONNECT requests (and relying on various 
> ephemeral side effects of those malformed requests), but there may be 
> other ways to handle this better.
>
> Example A: Squid could auto-extract host:port parts from the URI 
> received from a url_rewrite_program when adapting a CONNECT request. 
> The new behavior may need to be explicitly allowed by a new 
> url_rewrite_program parameter, but perhaps that is not necessary. The 
> actual proposal should finalize/defend this design decision.
>
> Example B: Squid could deny a request that receives a malformed 
> url_rewrite_program response (e.g., using ERR_GATEWAY_FAILURE). I wish 
> the original implementation would do that instead of ignoring the 
> problem[^1]! For backward compatibility, a new url_rewrite_program 
> parameter could allow old "report and ignore" behavior, but perhaps 
> that is not necessary. The actual proposal should finalize/defend this 
> design decision.
>
> [^1]: Squid already uses ERR_GATEWAY_FAILURE for url_rewrite_program 
> timeouts AFAICT.
>
>
Yes, I know you position.

Thank you!




More information about the squid-users mailing list