> > There is no magic involved here. > > Apps *know* when to perform reads, and when not to perform reads. > The middleware doesn't because it is protocol ignorant (it is used > by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc). > > Think of a simple HTTP-based server app receiving a HTTP/1.0 request > from a TLS-stack on top of a blocking network socket. If the App would > keep calling SSL_read() (for an OpenSSL-style API), it would get stuck > (blocked on read), and at some point the client would give up and > close the connection (with close_notify or TCP RST), and the server > waking from either the processing of the close_notify or the TCP RST > would be unable to deliver a response (which the client would not read > anyway).
This is an example of the application not knowing which channels are ready. So no the app doesn't "know when to read". > > 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. > > With TLS up to TLSv1.2 streaming is no problem, the middleware can > easily recognize non-AppData records and avoid passing them to > the TLS stack for processing unless the application explicitly asks > the middleware to do so. When TLSv1.3 hides the ContentType, > the fact that a close_notify was received & processed can only be > determined after the fact, when the shattered pieces are on the floor. > Communication in the other direction will be impossible, and it will > not be possible to prevent this from happening. > > While it is conceivable to jump hoops and implement new APIs and > callback for the TLS stack to allow the middleware instrumenting > and holding off the processing of TLS close_notify, this is not > going to allow a drop-in replacement of an existing TLSv1.2 with > a ContentType-hiding TLSv1.3 implementation underneath an existing > application. Yes, you will need to update the middleware component as well. Why is this a problem? > > For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty. > We were able just fine to drop-in a TLSv1.2 implementation underneath > apps that were originally built on top of an SSLv3-only stack. > > > > > > > Can you explain further why this is a problem: are you expecting that > > if you send application data to the client after sending the close_notify > > itself, the client will consume it? > > > > Can you help me understand? > > TCP is a full-duplex communication channel and allows shutdown for each > of the two communication directions performed independently. There are > existing communication protocols (other than HTTP) that _use_ independent > shutdown, and may want to continue using it even after starting to > protect their original cleatext communication with TLS. > > > 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 alerts trigger teardown of both sides. There is no half open state for TLS. Nginx manages fine on OpenSSL. > > If you don't know: SSL_write() will fail, because OpenSSL will push out > a close_notify alert from within SSL_read(), and make the connection > unusable. Being able to distinguish AppData records from non-AppData > records, an application caller of SSL_read() (such as my middleware) > can prevent loosing the backchannel with no prior warning -- if it > wants to. For streaming operation, my middleware DESPERATELY wants to > prevent the communication channel becoming unusable in both directions > _before_ the application has received/seen all the app data from the channel. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
