<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 22, 2015 at 12:43 AM, Yawning Angel <span dir="ltr"><<a href="mailto:yawning@schwanenlied.me" target="_blank">yawning@schwanenlied.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Fri, 21 Aug 2015 17:51:20 -0700<br>
Kevin P Dyer <<a href="mailto:kpdyer@gmail.com" target="_blank">kpdyer@gmail.com</a>> wrote:<br>
<br>
> On Wed, Aug 19, 2015 at 11:58 AM, Yawning Angel<br>
> <<a href="mailto:yawning@schwanenlied.me" target="_blank">yawning@schwanenlied.me</a>> wrote:<br>
><br>
> > [snip]<br>
> ><br>
> > The FTE semantic attack they presented isn't the easiest one I know<br>
> > of (the GET request as defined by the regex is pathologically<br>
> > malformed).<br>
> ><br>
><br>
> Very interesting! This is news to me. I'm assuming I did something<br>
> silly. (Even though I tested it against bro, wireshark, etc.)<br>
<br>
</span>Huh. I brought it up in conversation with a few people and was under<br>
the impression it was passed on.  I probably should have e-mailed you<br>
about it or something.<br>
<span><br>
> How is it pathologically malformed?<br>
<br>
</span> "manual-http-request": {<br>
   "regex": "^GET\\ \\/([a-zA-Z0-9\\.\\/]*) HTTP/1\\.1\\r\\n\\r\\n$"<br>
 },<br>
<br>
No "Host" header.  All complaint requests MUST include one per RFC<br>
2616, and all compliant servers MUST respond with a 400 if it is<br>
missing.<br></blockquote><div><br></div><div>Ah, gotcha. It's not RFC compliant. RFC2616 was created in 1999 and there are tons of HTTP-like implementations since then that, ostensibly, don't need to follow it. (e.g., an HTTP-like client/server that only talk to each other.) A network monitor must deal with these cases too, and they'll broadcast HTTP/1.1 in their headers.</div><div><br></div><div>This [1] paper is a bit dated (2007) but my intuition is that real-world implementations have drifted even further from the RFC over the last 8 years. I swear there's a more recent paper on this topic, but I couldn't find it...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Since requests of that sort should invoke the error path on RFC<br>
compliant servers it's a really good distinguisher since legitimate<br>
clients will not do such a thing.  Existing realistic adversaries<br>
already have "identify 'suspicious behavior', call back to confirm"<br>
style filtering in production, so false positive rate can be reduce to<br>
0 if needed.<br></blockquote><div><br></div><div>Based on our exploration of data, we found there's a wide range of implementations and most of which have non-RFC-compliant behaviors. See Section 4 of our paper for more details. For that reason I'd be very surprised if a host-header-check could result in a 0 FP rate.</div><div><br></div><div>With that being said, I'll add the host-header-check to the list of experiments that we want to do for the full version of our paper. Would be interesting to learn what the data tells us.</div><div><br></div><div>-Kevin</div><div><br></div><div>[1] <a href="https://www.ideals.illinois.edu/bitstream/handle/2142/11424/Non-compliant%20and%20Proud%20A%20Case%20Study%20of%20HTTP%20Compliance.pdf">https://www.ideals.illinois.edu/bitstream/handle/2142/11424/Non-compliant%20and%20Proud%20A%20Case%20Study%20of%20HTTP%20Compliance.pdf</a></div></div></div></div>