[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