[openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE

[Jakob Bohm]

On 10/03/2015 20:10, Serj Rakitov wrote:
> 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?
>
There is lots of mention of renegotiation (what you call
rehandshaking) in the OpenSSL documents and discussions,
so I am reasonably sure it can be done.  It also seems
there are secure and insecure ways to do it.  I don't
know the details though.

This implies that the general rules about applications
using non-blocking sockets having to always handle the
possibility of WANT_READ/WANT_WRITE at any time might be
invoked by renegotiation scenarios at any time.  Because
the rules say "at any time", there is no specific
discussion of applying those rules at specific times
(such as during renegotiation).

>
> 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).
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded