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!
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
