After authentication occurs, the client and server must agree on a symmetric encryption method and generate a single encryption key to use for data encryption. The chosen key is exchanged by using the PKI method of encryption. After the symmetric encryption algorithm (such as AES) and a single encryption key are chosen, all data exchanges use this algorithm and key instead of the PKI method of encryption.
In an SSL-encrypted session, all data is encrypted with the symmetric encryption algorithm immediately before it is sent to the client. Data from the client is decrypted immediately after it is received. The encryption algorithm that is used for the connection depends on a combination of the following factors:
During the SSL handshake, the client sends a list of encryption algorithms it is able to use. The server submits its list and the SSL subsystem picks an algorithm that all parties support, giving preference to the order that the server specifies. If the server does not support any of the encryption algorithms that the client requests, the connection is closed. Several z/OS® Communications Server applications use the SSL support that is provided by the System Secure Sockets Layer (System SSL) element of z/OS. The encryption algorithms that the servers and client support depend on the level of System SSL that is installed. The following encryption algorithms are supported by the base level of System SSL:
The System SSL Level 3 feature is required for Triple DES, AES, and RC4 non-export (128 bit) encryption algorithms. The encryption algorithm list can be customized for the servers and client to a subset of the System SSL list. For specific server and client statements that are used to create the encryption list, see the security information for the appropriate server or client.
Encryption is provided by either hardware, if available, or software algorithms within System SSL or Integrated Cryptographic Services Facility (ICSF). There is no TCP profile definition to control whether the cryptographic hardware is used for secure connections. For information about cryptographic hardware usage within System SSL, see z/OS Cryptographic Services System SSL Programming. To use FIPS 140 mode, ICSF must be started and available to System SSL.
If hardware encryption is to be used, be sure that the RACF® user ID associated with the server has read access to the RACF CSFSERV class resources. If ICSF is available but the server has not been given access to these resources, the SSL initialization may fail. The reason code is likely to be 4 (bad password) because System SSL will attempt to use the hardware encryption during processing of the key ring.