> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of pratyush parimal > Sent: Wednesday, December 06, 2017 12:55 > But what I don't understand is, why does the library need to re-do the handshake? I don't wish to sound rude, but this is answered right in the OpenSSL documentation for the SSL error codes: "This is mainly because TLS/SSL handshakes may occur at any time during the protocol (initiated by either the client or the server)". *Either side* can initiate a new handshake. Unless you control the TLS implementations on both sides, you can't guarantee there won't be new handshakes. Or at least that used to be the case. TLSv1.3 got rid of renegotiation, so if you have a TLSv1.3 connection, it will never renegotiate. However, you could still get at least SSL_ERROR_WANT_WRITE. Why? Because the peer could send something that your side has to respond to. For example, it could erroneously try to renegotiate, and now you need to send an alert. WANT_READ / WANT_WRITE are part of life with TLS. You'll just have to handle them. Complicated protocols are complicated. If you're wondering why renegotiation happens in pre-TLSv1.3 versions, you can find various articles online suggesting some of the more plausible (though probably not terribly common) scenarios. Probably the most common is needing to re-key because enough data has been transmitted that a passive attacker could derive some information about the key. It's also possible that the initial connection did not involve a client certificate, but now one side or the other has decided the client should send one. I've never seen that happen but I've seen it suggested. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
