On 19/07/18 04:56, Eliezer Croitoru wrote: > Hey Squid-Dev’s, > > > > Currently Squid-Cache forces Host Header Forgery on http and https requests. > > - https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery >
Forces? no. Prevents. > Squid is working properly or “the best” when the client and the proxy > use the same DNS service. > > In the past I have asked about defining a bumped connection as secured > and to disable host header forgery checks on some of these. > Having a connection be bumped does not mean the requests decrypted from that connection are meant for that server. DONT_VERIFY_PEER and such false "workaround" are still very common things for admin to do. A client or intermediary can as easily forge the SNI value on TLS setup as a Host header in plain-text HTTP. The resulting problems in both cases are the same. > The conditions are: > > - Squid validates that the server certificate is valid against > the local CA bundles (an admin can add or remove a certificate manually > or automatically) > > - The admin defines an external tool that verifies and/or > allows host header forgery to be disabled per request. > > > > I am in the middle of testing 4.1 and wondering what is expected from > 4.1 regarding host header forgery. > > Was there any change of policy? > No changes from Squid-3 are expected in terms of these checks. There may be changes in TLS handling which decrypt more (or less) requests. Any requests which *are* decrypted, the initial CONNECT (from SNI) are expected to be verified. TPROXY / NAT intercepted traffic is verified against the against the dst-IP of the intercepted client TCP connection. Bumped and non-intercepted traffic (in strict verify mode) against the server-IP from initial client CONNECT tunnel. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
