Re: [squid-users] Reverse DNS lookups from squid logging port
On 1/24/22 7:24 PM, Praveen Ponakanti wrote: > Hi, > > I am running squid version 4.17 and have not been able to disable the > reverse DNS lookups it does on each client's IP address. Found the > thread below that discusses this; I have attempted adding the following > config knobs, but it still does not disable the reverse lookups. I do > not have any logformat containing ">A" or " > store_id_extras "%>a %un %>rm myip=%la myport=%lp" > url_rewrite_extras "%>a %un %>rm myip=%la myport=%lp" > > http://lists.squid-cache.org/pipermail/squid-users/2016-February/009109.html > > The proposed solution seems to be to change the following lines and > recompile. If this is still the recommended fix, can it be upstreamed in > an upcoming release? > > https://github.com/squid-cache/squid/blob/master/src/cf.data.pre#L6042 > https://github.com/squid-cache/squid/blob/master/src/cf.data.pre#L6136 The above change of squid.conf defaults will probably work for you, but it will also break some deployments affected by this bug because the current code implicitly relies on those defaults triggering lookups. Thus, it is probably not the right solution for upstreaming. The PR mentioned below discusses specifics (see item #1 in the PR description). The solution proposed for upstreaming is at https://github.com/squid-cache/squid/pull/912 It does not require changing squid.conf defaults and has no (known to me) other serious flaws. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] 4.17 and 5.3 SSL BUMP issue: SSL_ERROR_RX_RECORD_TOO_LONG
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: ngtech1...@gmail.com > > -Original Message- > From: squid-users On Behalf Of > Alex Rousskov > Sent: Monday, January 24, 2022 16:54 > To: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] 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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] 4.17 and 5.3 SSL BUMP issue: SSL_ERROR_RX_RECORD_TOO_LONG
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. Thanks, Eliezer * Tested to work in my specific scenario which I really don't care about caching when I'm in a DOS situation. Eliezer Croitoru Tech Support Mobile: +972-5-28704261 Email: ngtech1...@gmail.com -Original Message- From: squid-users On Behalf Of Alex Rousskov Sent: Monday, January 24, 2022 16:54 To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] 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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] 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_feature.2C_enhance.2C_of_fix_something.3F HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
