[squid-users] issues with sslbump and "Host header forgery detected" warnings

[Alex Rousskov]

On 11/6/20 4:18 PM, Leonardo Rodrigues wrote:

> 2020/11/06 18:04:21 kid1| SECURITY ALERT: Host header forgery detected...
> 2020/11/06 18:04:21 kid1| SECURITY ALERT: on URL:...

> - without using WPAD or without configuring proxy on the client
> devices, is this somehow "fixable" ?

Yes, it is possible to modify Squid to correctly forward the intercepted
TCP connection where it was going despite the host validation failure.
Squid already does that for some use cases, but that code currently
excludes intercepted TLS connections (among other cases).


>     - is there any chance the NONE/409 (Conflict) logs i'm seeing are
> not related to this? Maybe these are just WARNINGs and not ERRORs, or
> these would really cause a fail to the intercepted connection?

Bugs notwithstanding, your Squid is terminating the TLS connection after
printing the _second_ ALERT line above:

> debugs(85, DBG_IMPORTANT, "SECURITY ALERT: on URL: " << ...
> // IP address validation for Host: failed. reject the connection.
> repContext->setReplyToError(ERR_CONFLICT_HOST, Http::scConflict,

The documented intent of that code path is to eventually terminate the
TLS connection without contacting the origin server. I suspect that is
what actually happens, but I did not check. You can check this
(indirectly) by reproducing the problem while capturing client<->Squid
and Squid->server traffic.


>     - any other hint on this one without having to set proxy, in any
> way, on the clients? I just wanna have hostnames (and traffic generated)
> logged, no need for full decrypt (bumping) of the connections.

You have a use case where connection rejection is not the best handling
option. Implementing and defending proper support for that specific use
case is probably not trivial, but I think it is doable.

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Alex.