[squid-users] host_verify_check behaviour in intercept mode for domain behind Loadbalancer ( multiple IPs )
Amos Jeffries
squid3 at treenet.co.nz
Tue May 16 14:03:15 UTC 2023
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
More information about the squid-users
mailing list