On 11/09/2016 01:42 PM, Martin Rex wrote: > Whether or not the calling App wants to shutdown a communication > at different times in both directions depends on the existing semantics > of that application (which has just added TLS protection around its > communication). Reading and processing a close_notify in the TLS stack > (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude > any further of sending of responses by the application, so the middleware > really will want to hold of processing of close_notify alerts unless > _explicitly_ asked to read further AppData by the application.
I don't understand. As Watson notes, TLS does not have a half-closed state. So, if the application wants to continue receiving data, the application protocol should not [inform the TLS stack to] generate a close_notify until the entire application-layer protocol is done, in both directions. Maybe that would work on plain TCP (no TLS), but I just don't see how this should be expected to always work with TCP+TLS between endpoints using different implementations. -Ben
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
