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.

ICSF is recommended for the storage of the private keys associated with digital certificates, because it is a more secure solution than non-ICSF private key management. ICSF ensures that private keys are encrypted under the ICSF master key and that access to them is controlled by general resources in the CSFKEYS and CSFSERV security classes. In addition, operational performance is improved because ICSF utilizes the hardware Cryptographic Coprocessor. See Cryptographic Services ICSF Administrator's Guide (SA22-7521) for more details about ICSF and how to control who can use cryptographic keys and services.

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

The GSK_PROTOCOL_* variables in rse.env allow you to control which protocols can be used for encrypted communication. The GSK_V3_CIPHER_SPECS variable in rse.env allows you to control which ciphers can be used for encrypted communication. The GSK_FIPS_STATE variable in rse.env allows you to enforce FIPS 140-2 compliant encrypted communication. These variables are documented in "rse.env, the RSE configuration file" chapter in the Host Configuration Guide (SC27-8437).

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).