[openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE

[Serj Rakitov]

Hi, Jakob. Thanks for reply.

Now I have seen OpenSSL code and something clear for me.

WANT_READ/WANT_WRITE it's just an implementation for "WOULDBLOCK": not fatal error for non-blocking IO. So, for example for socket and Windows it's just WSAEWOULDBLOCK returns by WSAGetLastError. Peforms by BIO_sock_should_retry/BIO_sock_non_fatal_error in sock_read/sock_write.

There was some incomprehension for me because I forgot that SSL_read/SSL_write can perform a handshake if it didn't happen before. This is the key, because if handshake took place when SSL_write never will want read(to my mind), because it's just perform writesocket(send) operation. 

But with Rehandshaking (renegotiation) still incomprehension... I don't know why there is a silence about this here and in the net! 

I have read Eric Rescorla's old(January 10, 2002) article and there he told about Rehandshaking on the Server and on the Client, so it's possible with OpenSSL, but maybe in newer versions of OpenSSL it is not possible?

Jakob, can you tell me: is it possible to renegotiate a connection in OpenSSL? And if yes how to do it right?



10.03.2015, 19:06, "Jakob Bohm" <jb-openssl at wisemo.com>:
> Not having tested or read the relevant OpenSSL code, I
> presume that SSL_write could want a read if it has sent
> a handshake message, but not yet received the reply, thus
> it cannot (encrypt and) send user data until it has
> received and acted on the handshake reply message.
>
> Maybe the easier scenarios are at the start of a session,
> where the initial handshake has not yet completed, as
> happens in a HTTPS client (always writes a request before
> the first read) or a simple SMTPS server (always writes a
> banner line before the first read of client commands,
> except in some servers that do an early read to check if
> a broken/spammer client is trying to send before receiving
> the banner).