TLSv1.3 enablement may require changes to GSKit client to prevent GSK_WOULD_BLOCK or EWOULDBLOCK advisory condition

The enablement of TLSv1.3 altered the code path in System TLS, resulting in latency and response time improvements for some operations. This has exposed secure non-blocking sockets applications that do not handle a blocking condition. Based on timing, some invocations of the gsk_secure_soc_read() or SSL_Read() API reach a block condition before the remote data is available from the wire. This results in GSK_WOULD_BLOCK returned for gsk_secure_soc_read() API or SSL_ERROR_IO with errno set to EWOULDBLOCK for the SSL_Read() API. These advisory return codes notify the application to retry the read operation. However, some applications treat the return codes as fatal.

TLS reads will fail during the read operation resulting in a TLS read error. The symptom of this situation is that gsk_secure_soc_read() or SSL_Read() API completes and no data is returned.

To resolve this issue, switch your GSKit client application to implement retry logic or use blocking sockets and set the GSK_IBMI_READ_TIMEOUT attribute to the number of seconds you wish to block before timing out the secure connection. This would be set by the gsk_attribute_set_numeric_value() API after the gsk_environment_open() API is called. You would set this attribute along with any other GSKit attributes being set before the gsk_environment_init() API is called.

For more information on this and detailed instructions, see the IBM Support page here: https://www.ibm.com/support/pages/node/6237392