<div dir="ltr"><div><span class="im" style="font-size:12.8px">> > > As far as I understand, just looking for TCP FIN should be good<br>> > > enough for this task.<br>> ><br>> > TCP FIN can not be authenticated. A man in the middle can make one.<br>><br></span><span style="font-size:12.8px">> The same is true for close_notify with your patch. </span><br></div><div><br></div>close_notify is encrypted using the current session state.<div>A MITM cannot spoof a close_notify if it does not have the keys.<div><br></div><div><br></div><div><span style="font-size:12.8px">> Just keeping </span><span style="font-size:12.8px">in mind that no close_notify means that the</span></div><div><span style="font-size:12.8px">> response may be </span><span style="font-size:12.8px">truncated should work.  Note well that</span></div><div><span style="font-size:12.8px">> if it's client who closes </span><span style="font-size:12.8px">the connection it's likely that the</span></div><div><span style="font-size:12.8px">> response is truncated (or the </span><span style="font-size:12.8px">HTTP layer has enough</span></div><div><span style="font-size:12.8px">>  information to check that it wasn't).</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Sorry if this is incorrect, but isn't it easy to tell if a</span></div><div><span style="font-size:12.8px">response is truncated in HTTP/1.1 at the</span></div><div><span style="font-size:12.8px">HTTP protocol layer?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Again I want to reiterate that truncation is NOT my</span></div><div><span style="font-size:12.8px">concern (although I agree it IS important). My</span></div><div><span style="font-size:12.8px">setting involves releasing keys to a trusted monitor</span></div><div><span style="font-size:12.8px">with read-only privileges, on the </span><span style="font-size:12.8px">client's behalf</span></div><div><span style="font-size:12.8px">(such as an exfiltration detector). The client needs</span></div><div><span style="font-size:12.8px">to protect the integrity of its session, and must</span></div><div><span style="font-size:12.8px">ensure that the key can not be used to masquerade</span></div><div><span style="font-size:12.8px">as the client to the server.</span></div><div><span style="font-size:12.8px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 5:34 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Tue, Dec 08, 2015 at 01:21:41PM -0800, Judson Wilson wrote:<br>
<br>
> > As far as I understand, just looking for TCP FIN should be good<br>
> > enough for this task.<br>
><br>
> TCP FIN can not be authenticated. A man in the middle can make one.<br>
<br>
</span>The same is true for close_notify with your patch.  Just keeping<br>
in mind that no close_notify means that the response may be<br>
truncated should work.  Note well that if it's client who closes<br>
the connection it's likely that the response is truncated (or the<br>
HTTP layer has enough information to check that it wasn't).<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div><br></div>