Service Bulletin 158: Disabling of SSL_renegotiate() function due to integrity problem

An integrity problem with the renegotiate function in the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocol standard has been identified. Therefore, the SSL_renegotiate() function is being disabled in the TPF 4.1 system by APAR PJ37088 and in the z/TPF system by APAR PJ37087.

The information in the following paragraphs applies to TPF 4.1 APAR PJ37088 and z/TPF APAR PJ37087:

The SSL_renegotiate() function now will return an error code of 0 in all cases. If a renegotiate request is received from a remote system over an SSL session, the request will be ignored. This change pertains to SSL version 3.0 and TLS version 1.0.

Remove any SSL_renegotiate() function calls from your TPF application programs or change those programs so that they continue running even if an error is returned.

If APAR PJ37087 or PJ37088 is applied with loadset (ZOLDR) while SSL sessions are active, you must stop and restart those SSL sessions to disable the renegotiate function.

The information in the following paragraph applies only to z/TPF APAR PJ37087:

With z/TPF WebSphere MQ support for SSL, (PJ34481), the Queue Manager might issue the SSL_renegotiate() function on behalf of the channel. To check if your Queue Manager is issuing the SSL_renegotiate() function, enter ZMQSC DISPLAY QMGR and verify that SSLRKEYC is equal to zero. For any value other than zero, the Queue Manager will issue the SSL_renegotiate() function. In order to bypass issuing the SSL_renegotiate() function, enter ZMQSC ALT QMGR-queuemgrname SSLRKEYC-0, where queuemgrname is your Queue Manager name. If SSLRKEYC is not zero, any sender channel might fail with the following message:

MQSC0375E CHANNEL - channelname STOPPED SSL KEY RESET FAILED