Blocking IO IO on SSL Connections

132 Typically, using blocking IO alleviates the complications of retrying failed calls. With SSL, this is not the case. There are times when a call to SSL_read or SSL_write on a blocking connection requires a retry.

5.2.2.2 Blocking IO

Blocking IO means that an operation will wait until it can be completed or until an error occurs. Thus, with blocking IO in general, we shouldnt have to retry an IO call, since a single calls failure indicates an error with the communication channel, such that the channel is no longer usable; with blocking IO using OpenSSL, this is not true. The SSL connection is based upon an underlying IO layer that handles the actual transfer of data from one side to the other. The blocking property of an SSL connection is based solely on the underlying communication layer. For instance, if we create an SSL connection from a socket, the SSL connection will be blocking if and only if the socket is blocking. It is also possible to change this property in a connection weve already established; we change the property on the underlying layer and then handle all SSL IO functions appropriate for the new paradigm. Conceptually, SSL_read and SSL_write read and write data from the peer. Actually, a call to SSL_read may write data to the underlying IO layer, and a call to SSL_write may read. This usually occurs during a renegotiation. Since a renegotiation may occur at any time, this behavior can cause unexpected results when using a blocking IO layer; namely, an IO call may require a retry. Thus, our implementation must handle this. In order to handle a blocking call correctly, we need to retry the SSL IO operation if we receive SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE . Dont let the names of these errors confuse you. Even though they tell us the SSL connection needs to wait until we can read or write, respectively, we just need to retry whatever operation caused the condition. For instance, if an SSL_read caused the SSL_ERROR_WANT_WRITE error, we must retry the SSL_read rather than making the call to SSL_write . It is worth taking a moment to understand the potential errors for a single IO call. Though nonintuitive, a call to SSL_read may indeed return the error SSL_ERROR_WANT_WRITE due to the possibility of renegotiations at any point. In many ways, implementing a blocking call is similar to implementing a non-blocking one. Its similar in the sense that we must loop for retries, but it differs in that we dont need to check for IO availability on the underlying layer, as with poll or select . In the end, we will not show an example of looping to accomplish the blocking call; there is an easier way. Using the SSL_CTX_set_mode function or its counterpart for SSL objects, SSL_set_mode , we can set some IO behaviors of SSL connections. The second parameter is a set of defined properties joined with the logical OR operator. SSL_MODE_AUTO_RETRY is one such mode. Setting this on a blocking SSL object or on the context that will create a object will cause all IO operations to automatically retry all reads and complete all negotiations before returning. Using this option allows us to implement IO as simply as normal blocking IO with the system calls read and write . In general, we should set this option on the SSL_CTX object before creating the SSL object. We can set the option later on the SSL object itself, but its best to do so before any calls to IO routines on that object. If we elect not to use this option and instead implement our blocking IO with our own loops, we might fall into a few traps. This is due to some special requirements for function call retries, which are detailed with our discussion of non-blocking IO.

5.2.2.3 Non-blocking IO