<div dir="ltr"><span style="font-size:12.8px">> There is a problem with this change: in most cases in practice</span><br style="font-size:12.8px"><span style="font-size:12.8px">> close from a client means that the socket is no longer open, and</span><br style="font-size:12.8px"><span style="font-size:12.8px">> trying to send a close_notify alert won't do anything good but</span><br style="font-size:12.8px"><span style="font-size:12.8px">> will result in RST instead.  Common practice seems to be don't</span><br style="font-size:12.8px"><span style="font-size:12.8px">> send close_notify alerts in such a case (e.g., I see Chrome doing</span><br style="font-size:12.8px"><span style="font-size:12.8px">> the same), and section 7.2.1 mentions this as well.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The behavior I am attempting to produce matches what I am</span></div><div><span style="font-size:12.8px">observing in the Apache web server (assuming default</span></div><div><span style="font-size:12.8px">configuration), so it's not unheard of for HTTPS.</span></div><div><br></div><div><span style="font-size:12.8px">> If you still think that changes in this area are needed - please</span><br style="font-size:12.8px"><span style="font-size:12.8px">> provide some more details on what you are trying to fix.</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I am researching ways of auditing TLS communications</span></div><div><span style="font-size:12.8px">in a read-only way. One method of achieving this is by having the TLS</span></div><div><span style="font-size:12.8px">client give the keyblock to an auditor after the client is sure that the server</span></div><div><span style="font-size:12.8px">will not accept any more data protected by the keys (assume the software</span></div><div><span style="font-size:12.8px">for the client and server are controlled by the same party). From my</span></div><div><span style="font-size:12.8px">investigation </span><span style="font-size:12.8px">of nginx and apache, if a client receives close_notify,</span></div><div><span style="font-size:12.8px">they can be assured </span><span style="font-size:12.8px">that no more data will be accepted by the server</span></div><div><span style="font-size:12.8px">under the key (both </span><span style="font-size:12.8px">web server software packages immediately</span></div><div><span style="font-size:12.8px">destroy the SSL object after calling SSL_shutdown).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Unfortunately, nginx </span><span style="font-size:12.8px">has this case where a client would attempt to</span></div><div><span style="font-size:12.8px">close a connection, but </span><span style="font-size:12.8px">never get close_notify in response.</span></div><div><span style="font-size:12.8px">It seems like simply </span><span style="font-size:12.8px">obeying the TLS standard would fix this.</span></div><div><span style="font-size:12.8px">(close_notify IS sent on "connection: close" header or</span><span style="font-size:12.8px"> keepalive</span></div><div><span style="font-size:12.8px">timeout</span><span style="font-size:12.8px"> as I would expect.)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> Note well that section 7.2.1 you refer to is about avoiding</span><br style="font-size:12.8px"><span style="font-size:12.8px">> truncation attacks.  On the other hand, the code path you are</span><br style="font-size:12.8px"><span style="font-size:12.8px">> editing doesn't ensure that a close_notify notify alert was</span><br style="font-size:12.8px"><span style="font-size:12.8px">> received from the other side.  That is, sending a close_notify</span><br style="font-size:12.8px"><span style="font-size:12.8px">> alert will make truncation attacks easier, not stop them.</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Yes truncation attacks were not on my mind - that's a different</span></div><div><span style="font-size:12.8px">problem.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'd be happy to look into this a further if you think this work has</span></div><div><span style="font-size:12.8px">a chance of being incorporated.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks,</span></div><div><span style="font-size:12.8px">Judson</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 10:31 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>
<div><div class="h5"><br>
On Sat, Dec 05, 2015 at 07:17:54AM +0000, Judson Wilson wrote:<br>
<br>
> # HG changeset patch<br>
> # User Judson Wilson <<a href="mailto:wilson.judson@gmail.com">wilson.judson@gmail.com</a>><br>
> # Date 1449296759 0<br>
> #      Sat Dec 05 06:25:59 2015 +0000<br>
> # Node ID f41799d322f02c8998a800953d81e7274a9d3376<br>
> # Parent  cb31017e961b4a54e83c4fc1be46c18842696207<br>
> SSL: shutdown cleanly when other endpoint starts shutdown<br>
><br>
> Before this change, if the other endpoint sends an SSL close_notify, nginx<br>
> will kill the SSL connection without sending a close_notify in response.<br>
> This behavior does not follow RFC 5246 section 7.2.1:<br>
><br>
>   Unless some other fatal alert has been transmitted, each party is<br>
>   required to send a close_notify alert before closing the write side<br>
>   of the connection.<br>
><br>
> This change fixes this behavior in this specific situation, causing<br>
> nginx to reply with a close_notify before shutting down the conneciton.<br>
><br>
> diff -r cb31017e961b -r f41799d322f0 src/event/ngx_event_openssl.c<br>
> --- a/src/event/ngx_event_openssl.c   Wed Dec 02 19:17:19 2015 -0800<br>
> +++ b/src/event/ngx_event_openssl.c   Sat Dec 05 06:25:59 2015 +0000<br>
> @@ -1472,7 +1472,6 @@<br>
>      }<br>
><br>
>      c->ssl->no_wait_shutdown = 1;<br>
> -    c->ssl->no_send_shutdown = 1;<br>
><br>
>      if (sslerr == SSL_ERROR_ZERO_RETURN || ERR_peek_error() == 0) {<br>
>          ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0,<br>
> @@ -1480,6 +1479,8 @@<br>
>          return NGX_DONE;<br>
>      }<br>
><br>
> +    c->ssl->no_send_shutdown = 1;<br>
> +<br>
>      ngx_ssl_connection_error(c, sslerr, err, "SSL_read() failed");<br>
><br>
>      return NGX_ERROR;<br>
<br>
</div></div>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>
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>
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>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br></div>