On 1/24/22 1:06 PM, Eliezer Croitoru wrote: > I sat for a while thinking what is the best approach to the subject and the > next patch seems to be reasonable enough to me: > https://gist.github.com/elico/630fa57d161b0c0b59ef68786d801589 > Let me know if this patch violates anything that I might not took into > account. The squid-users mailing list is not a good place for code reviews. If you think your changes should be made official, please submit a pull request on GitHub: https://wiki.squid-cache.org/MergeProcedure FWIW, I wonder whether we should reuse and/or extend host_verify_strict instead of adding a new squid.conf directive to control this behavior. All other factors being equal, it would be good to have one directive to control Host validation and its direct effects. > * Tested to work in my specific scenario which I really don't care about > caching when I'm in a DOS situation. When one disables checks, Squid will continue to "work", of course. Did you verify that the patched Squid: 1. Goes to the intended destination IP address rather than to Host? 2. Does not evict the matching cached responses from the cache? 3. Does not satisfy the forged request from the cache? 4. Does not share responses to requests with the "forged" Host? There may be other prerequisites, and the above four may need polishing, but these are the first conditions that come to my mind when dealing with forgery attacks. Please disclose this information when/if posting your changes for the Project review on GitHub. Thank you, Alex. > ---- > Eliezer Croitoru > Tech Support > Mobile: +972-5-28704261 > Email: ngtech1ltd@xxxxxxxxx > > -----Original Message----- > From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of > Alex Rousskov > Sent: Monday, January 24, 2022 16:54 > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: 4.17 and 5.3 SSL BUMP issue: > SSL_ERROR_RX_RECORD_TOO_LONG > > On 1/24/22 2:42 AM, Eliezer Croitoru wrote: >> 2022/01/24 09:11:20 kid1| SECURITY ALERT: Host header forgery detected on >> local=142.250.179.228:443 remote=10.200.191.171:51831 FD 16 flags=33 > (local >> IP does not match any domain IP) > > As you know, Squid improvements related to these messages have been > discussed many times. I bet the ideas summarized in the following old > email remain valid today: > > http://lists.squid-cache.org/pipermail/squid-users/2019-July/020764.html > > > If you would like to address browser's SSL_ERROR_RX_RECORD_TOO_LONG > specifically (the error in your email Subject line), then that is a > somewhat different matter: According to your packet capture, Squid sends > a plain text HTTP 409 response to a TLS client. That is not going to > work with popular browsers (for various technical and policy reasons). > > Depending on the SslBump stage where the Host header forgery was > detected, Squid could bump the client connection to deliver that error > response; in that case, the browser may still refuse to show the > response to the user because the browser will not trust the certificate > that Squid would have to fake without sufficient origin server info. > However, the browser error will be different and arguably less confusing > to admins and even users. > > https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feat > ure.2C_enhance.2C_of_fix_something.3F > > > HTH, > > Alex. > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
