Question

I’m reading an openssl programming tutorial.

I can’t let a server app to be blocked on any operation for a single connection,
hence I’ll use non-block sockets.

Since it seems, ssl handshaking takes place at ssl_accept and ssl_connect,
and this could be blocked, I’ll have to set socket to non-block before the ssl_accept call.

The tutorial doc says I need to handle SSL_ERROR_WANT_WRITE(plus SSL_ERROR_WANT_READ of course) on SSL_read because SSL rehandshaking could take place anytime.
And SSL_ERROR_WANT_READ on SSL_write for the same reason.

From the doc,

We get a WANT_WRITE if we’re trying
to rehandshake and we block on a
write during that rehandshake.

We need to wait on the socket to be
writeable but reinitiate the read
when it is

I’m confused on the part of “re”handshaking.
I’m not planning to save ssl state and reuse it (this is called session resumption?)
After the first handshaking I won’t have to deal with handshaking for the same connection.

I wonder if I still need to worry about WANT_WRITE on SSL_read and vice versa when I am not gonna use session resumption.

Thank you

Answer 1

Rehandshaking can be triggered by either side at any point during the connection. It doesn’t really have anything directly to do with session resumption.

So yes, if you want your application to be reliable, you should be prepared to handle both SSL_WANT_WRITE and SSL_WANT_READ no matter whether you are currently reading or writing.