I'm sorry for the confusion. It seems I was wrong about OpenSSL behaviour.
Watson Ladd wrote: > Martin Rex wrote: >> >> If you're vaguely familiar with OpenSSL: >> when SSL_read() has received and processed a TLS record with a >> close_notify alert, do you know what happens to further calls >> of SSL_write() of the same handle, which technically is >> _the_other_ communication direction. > > Is this the case? Actually -- no, I'm sorry. I looked at the OpenSSL code again, and it doesn't seem to do that on receipt of CLOSE_NOTIFY. (It's more than 10 years that I programmed on top of OpenSSL). CLOSE_NOTIFY seems to only be sent after an explict call of SSL_shutdown(), and connection state (for the other direction) does not seem to be harmed by receipt CLOSE_NOTIFY, nor by sending of CLOSE_NOTIFY (warning-level) alerts. Only the communication direction that carried CLOSE_NOTIFY seems (properly) defunct (ignoring further IO requests). It seems that I was mislead by the semantics described in the TLS specification. > > Actually alerts trigger teardown of both sides. There is > no half open state for TLS. Nginx manages fine on OpenSSL. Teardown of both sides applies to fatal Alerts only. One of the reason for warning level alerts is that they should not tear down the connection state, and close_notify (although the semantics described in rfc5246 suggest otherwise) should tear down only the direction on which it was sent. So essentially, TLS should allow half-closed state, and at least a glance over the OpenSSL code suggests that this implementation would support it. >From the sequence of (data processing) events, I still want to hold off processing of CloseNotify until all prior TLS AppData records are properly consumed by the application caller, so that when the code writes traces about the progress of processing a connection, the processing of the Alert will follow the passing of all prior AppData to the application, and never precede it. -Martin _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
