On Mon, Feb 02, 2015 at 09:23:19AM +0300, Serj wrote: > > http://tools.ietf.org/html/rfc5246#section-7.2.1 > > I read RFC. Have read "7.2.1. Closure Alerts" once again. > But this is the normative document. I ask: what in practise in terms of OpenSSL API? > > As I already said some servers don't send "close_notify" and just close the connection. If you close first, that's OK. Also OK, if there's an application-level end-of-data indication. For example, with SMTP client sends "QUIT<CRLF>" and server sends "221 Goodbye", there's no need to explicitly perform an SSL_shutdown(). However, Postfix does it by the book per TLSv1.0: if (SSL_shutdown() == 0) SSL_shutdown() with appropriate handling of WANT_READ/WANT_WRITE, timeouts, ... > >> And what about the best practice for shutdown of connection on the server > >> side? Is it mandatory to wait "close_notify" from client to be able to > >> save valid session for this client or not? If server close the connection > >> after all data has been sent to the client and don't receive "close_notify", > >> will be the session kept? > > > > http://tools.ietf.org/html/rfc5246#section-7.2.1 > > I ask: what in practise in terms of OpenSSL API? > If SERVER close the connection after all data has been sent to the client and will not wait for "close_notify" alert from CLIENT, will be the session kept and valid in OpenSLL API? It should be sufficient for the server to send its close notify without waiting for a client response. If the server destroys the SSL connection without calling SSL_shutdown() I am not sure whether the session remains cached. > I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid? Try it, see what happens. The client is certainly free to *try* to the reuse the session, worst-case the server will perform a full handshake anyway. -- Viktor.
