On 16/05/2023 6:52 pm, sachin gupta wrote:
Hi
We recently shifted to squid 5.9 and started seeing errors in
Transparent mode SECURITY ALERT: Host header forgery detected on
conn3615903 local=44.242.184.237:443 <http://44.242.184.237:443>
remote=10.109.176.240:8990 <http://10.109.176.240:8990> FD 28029
flags=17 (local IP does not match any domain IP)
This is not a error, it is a alert to what is going on. The client
10.109.176.240 is trying to connect to 44.242.184.237 requesting a
domain which DNS says is **not** hosted there.
What happens next depends on what Squid is able to do given the
transaction type.
Some are rejected as unable to continue, some are allowed to complete
under restricted handling.
Previously we were using
https://github.com/NethServer/dev/issues/5348. In addition we are
using client_dst_passthru off. When building 5.9, the patch was not
applied cleanly and we wanted to check if things worked without this
patch. They did not work.
Please clarify "things" and "did not work".
I did check the forum responses
https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery. and
https://docs.diladele.com/faq/squid/host_header_forgery.html. We
already support explicit proxy but that is not always an option. We
can create another patch to circumvent issues like ***. But I wanted
to know if there is a plan to make this check optional or there is
some way we can workaround this problem without changing the code.
Without this support, how can intercept mode work for any website
which is behind a loadbalancer with multiple IPs.
More recent version of Squid allow some more CONNECT traffic cases be
handled instead of rejected.
There are also some ideas on further improvements, but those are a long
way off.
Cheers
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
