<div dir="auto"><span style="font-family:sans-serif;font-size:13.696px">It's regarding active fingerprinting and mitigating attacks, not just it's passive use. (Sorry for the dbl send)</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 30, 2017 21:41, "Alex Rousskov" <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/30/2017 12:15 PM, Andrei wrote:<br>
> You do realize that there's nothing "weird" about p0f, right?<br>
<br>
Right. I do not know why you had to ask though: There is nothing related<br>
to p0f (i.e., a passive traffic analysis tool) in my response. And the<br>
original question is probably unrelated to p0f as well since active<br>
connection resets are incompatible with the idea of passive analysis.<br>
<br>
Alex.<br>
<br>
<br>
<br>
> On Mon, Oct 30, 2017 at 11:22 AM, Alex Rousskov wrote:<br>
><br>
>     On 10/30/2017 03:51 AM, Troiano Alessio wrote:<br>
><br>
>     > I've squid 3.5.20 running on RHEL 7.4. I have a problem to access<br>
>     > some websites, for example <a href="http://www.nato.int" rel="noreferrer" target="_blank">www.nato.int</a> <<a href="http://www.nato.int" rel="noreferrer" target="_blank">http://www.nato.int</a>>. This website apply an<br>
>     > Anti-DDoS system that reset the first connection after the TCP 3-way<br>
>     > handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections<br>
>     > are accepted. The website administrator say's it is by design.<br>
><br>
><br>
>     > When I browse the site with squid proxy the browser receive an "Empty<br>
>     > Response" squid error page (HTTP error code 502 Bad Gateway) and<br>
>     > doesn't do the automatic retry:<br>
><br>
>     This is by design as well :-).<br>
><br>
>     We can change Squid behavior to retry connection resets, but I am sure<br>
>     that some folks will not like the new behavior because in _their_ use<br>
>     cases a retry is wasteful and/or painful. IMHO, the new behavior should<br>
>     be controlled by a configuration directive, possibly an ACL-driven one.<br>
><br>
>     Quality patches implementing the above feature should be welcomed IMO.<br>
>     The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT<br>
>     handling inside FwdState::fail(). There is a similar code that handles<br>
>     persistent connection races there already, but the zero-size reply code<br>
>     may need a new dedicated FwdState flag to prevent infinite retry loops<br>
>     when the origin server is broken (a much more typical use case than the<br>
>     weird attempt at DDoS mitigation that you have described above).<br>
><br>
>     <a href="https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/<wbr>SquidFaq/AboutSquid#How_to_<wbr>add_a_new_Squid_feature.2C_<wbr>enhance.2C_of_fix_something.3F</a><br>
<br>
<br>
</blockquote></div></div>