<div dir="ltr"><span style="font-size:12.8px">> As far as I understand, just looking for TCP FIN should be good</span><br style="font-size:12.8px"><span style="font-size:12.8px">> enough for this task.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">TCP FIN can not be authenticated. A man in the middle can make one.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 5:15 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 Mon, Dec 07, 2015 at 02:38:14PM -0800, Judson Wilson wrote:<br>
<br>
> > There is a problem with this change: in most cases in practice<br>
> > close from a client means that the socket is no longer open, and<br>
> > trying to send a close_notify alert won't do anything good but<br>
> > will result in RST instead.  Common practice seems to be don't<br>
> > send close_notify alerts in such a case (e.g., I see Chrome doing<br>
> > the same), and section 7.2.1 mentions this as well.<br>
><br>
> The behavior I am attempting to produce matches what I am<br>
> observing in the Apache web server (assuming default<br>
> configuration), so it's not unheard of for HTTPS.<br>
<br>
</span>For sure it's not something unheard.  The question is mostly about<br>
balance of positive and negative results in a particular code<br>
path.  In this particular case it looks like nginx behaviour is<br>
good enough.<br>
<span class=""><br>
> > If you still think that changes in this area are needed - please<br>
> > provide some more details on what you are trying to fix.<br>
><br>
> I am researching ways of auditing TLS communications<br>
> in a read-only way. One method of achieving this is by having the TLS<br>
> client give the keyblock to an auditor after the client is sure that the<br>
> server<br>
> will not accept any more data protected by the keys (assume the software<br>
> for the client and server are controlled by the same party). From my<br>
> investigation of nginx and apache, if a client receives close_notify,<br>
> they can be assured that no more data will be accepted by the server<br>
> under the key (both web server software packages immediately<br>
> destroy the SSL object after calling SSL_shutdown).<br>
><br>
> Unfortunately, nginx has this case where a client would attempt to<br>
> close a connection, but never get close_notify in response.<br>
> It seems like simply obeying the TLS standard would fix this.<br>
> (close_notify IS sent on "connection: close" header or keepalive<br>
> timeout as I would expect.)<br>
<br>
</span>As far as I understand, just looking for TCP FIN should be good<br>
enough for this task.<br>
<span class=""><br>
> > Note well that section 7.2.1 you refer to is about avoiding<br>
> > truncation attacks.  On the other hand, the code path you are<br>
> > editing doesn't ensure that a close_notify notify alert was<br>
> > received from the other side.  That is, sending a close_notify<br>
> > alert will make truncation attacks easier, not stop them.<br>
><br>
> Yes truncation attacks were not on my mind - that's a different<br>
> problem.<br>
><br>
> I'd be happy to look into this a further if you think this work has<br>
> a chance of being incorporated.<br>
<br>
</span>I don't think that this change is needed, especially given the<br>
reasons for the change, and potentical security implications of<br>
the proposed patch.<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>