Encrypted communication

Note: Due to a vulnerability in the SSLv3 (Secure Socket Layer) protocol, support for this protocol is deprecated in z/OS® Explorer.

External (client-host) communication using RSE can be encrypted using Transport Layer Security (TLS). This feature is disabled by default and is controlled by the settings in ssl.properties. Refer to "(Optional) ssl.properties, RSE encrypted communications" in the Host Configuration Guide (SC27-8437).

RSE daemon and RSE server support different mechanisms to store certificates due to architectural differences between the two. SAF-compliant key rings are supported by both RSE daemon and RSE server, and are the preferred method for managing certificates.

SAF-compliant key rings can store the certificate's private key either in the security database or by using ICSF (Integrated Cryptographic Service Facility), the interface to z Systems® cryptographic hardware.

Note: ICSF does permission checks at thread level instead of process level when the private key is stored in the security database, which implies that each user ID that connects must have access to the private key of the server certificate.

RSE daemon uses System SSL functions to manage encrypted communications. This implies that SYS1.SIEALNKE must be program controlled by your security software and available to RSE via LINKLIST or the STEPLIB directive in rse.env.

The RSE user ID (stcrse in the following sample commands) needs authorization to access his key ring and the related certificates when SAF-compliant key rings are used for either RSE daemon or RSE server.
  • RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
  • RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
  • PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
  • PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
  • SETROPTS RACLIST(FACILITY) REFRESH
You can use various variables that are documented in rse.env, the RSE configuration file chapter in the Host Configuration Guide (SC27-8437) to control the encrypted communication:
  • Use the GSK_PROTOCOL_* variables in rse.env to control which protocols can be used for encrypted communication.
  • Use the GSK_V3_CIPHERS variable in rse.env to control which group of ciphers can be used for encrypted communication.
  • Use the GSK_V3_CIPHER_SPECS and GSK_V3_ CIPHER_SPECS_EXPANDED variables in rse.env to control which ciphers can be used for encrypted communication.
  • Use the GSK_SERVER_TLS_KEY_SHARES variable in rse.env to control which key share groups are used during the encryption handshake of TLS v1.3 or later versions.
  • Use the GSK_FIPS_STATE variable in rse.env to enforce FIPS 140-2 compliant encrypted communication.
Note:
  • z/OS Explorer will disable ciphers that are known to be insecure.
  • Implicit and explicit protocol and cipher selections are propagated by RSE daemon to RSE server.

See Setting up encrypted communication and X.509 authentication for more details on activating encrypted communications for z/OS Explorer.

Note: The z/OS Explorer client and host must have access to common encryption protocols and common cipher suite definitions to be able to set up encrypted communication. For information on Java™ cipher suite definitions used by the client and RSE server, see the developerWorks® Java technology security information site (http://www.ibm.com/developerworks/java/jdk/security/). For information on System SSL cipher suite definitions used by RSE daemon, see Cryptographic Services System SSL Programming (SC24-5901).