On 10/06/2016 6:09 a.m., Eng Hooda wrote: > Hello Squid Users, > I have just started using squid less than a week ago . > My setup is a transparent proxy with sslbump , I peek for media streaming sites then terminate their connections then I splice all. > I noticed that some https sites (not all of the time) , does not respond , when Investigated I found the following in cache.log : > > 3105 2016/06/09 12:45:40.630 kid1| SECURITY ALERT: on URL: mail.live.com:443 > 3106 2016/06/09 12:45:40.631 kid1| SECURITY ALERT: Host header forgery detected on local=157.55.43.16:443 remote=10.3.1.80:58328 FD 94 flags=33 (local IP does not match any domain IP) > 3330 2016/06/09 13:26:26.676 kid1| SECURITY ALERT: on URL: mail.live.com:443 > 3331 2016/06/09 13:26:26.676 kid1| SECURITY ALERT: Host header forgery detected on local=157.56.122.210:443 remote=10.3.1.80:58414 FD 141 flags=33 (local IP does not match any domain IP) > 3530 2016/06/09 13:49:49.481 kid1| SECURITY ALERT: on URL: mail.live.com:443 > 3531 2016/06/09 13:49:49.481 kid1| SECURITY ALERT: Host header forgery detected on local=157.55.43.17:443 remote=10.3.1.80:58616 FD 119 flags=33 (local IP does not match any domain IP) > > I searched for a solution which lead me to (1st result) : > http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery > > I read it and it seems to be a dead end . > > What I understood that client requested page from a certain IP , reply came from another IP then it's blocked for security reasons. > > > Well I tried to nslookup the mentioned IPs , and all of them are sub domains of mail.live.com No, all of them claim to be in their reverse-DNS responses. That is just the IP address owners view of things. In the case of an attack its the attackers opinion about what you should believe. Not safe. Forward-DNS results which provide the domain owners authoritative list of what IPs they are using. Say a different message contradicting those reverse-DNS results ... > also tried to nslookup mail.live.com , and every time I get different IPs > Exactly. So do Squid and the client. Which means Squid is almost always unable to see the IP the client is contacting as being a valid one for that domain. > nslookup mail.live.com > Server: google-public-dns-a.google.com > Address: 8.8.8.8 > It is a problem caused by Google DNS. The best way to get around it is to setup a recursive resolver on your network that is used by both Squid and clients. Diverting the client port 53 traffic to it if necessary. If you wish to use Google DNS after having that available, then 8.8.8.8 should be setup as a parent of that local resolver. Not as something Squid or client contact separately. That setup makes the google DNS results more often be cached in the shared resolver for long enough that Squid can see it when it does the validation steps. NP: there are other causes of this known, related to connection persistence, and SSL-Bump SNI being validated. They are bugs in Squid and still being worked on fixing. So dont expect the above to solve all instances of it. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
