Overview of an SSL Session

The general processing steps associated with an SSL connection are described here. Note that these steps are more descriptive of a static SSL connection for a z/VM® application server than for a TLS connection. For TLS, similar processing is performed, although the SSL server does not participate when the initial connection is established, since the connection is a clear connection (one that is not secured). The interaction with the SSL server occurs once a Handshake request is initiated by the client or the application server (with TLS, data encryption is often controlled at the direction of the client, through subsequent renegotiations for the duration of the connection). SSL and TCP/IP server interactions similar to those described would also be applicable to z/VM client programs that use TLS, when connections are established with a remote server.

An SSL session consists of the following general processing steps:

1. Connect

   A remote client sends a connection request for an application server. If the application server is listening on a secure port, the TCP/IP (stack) server sends this request to the SSL server. The TCP/IP server also sends a label that identifies the certificate to be used for the secure connection, as well as the socket addresses of the client and the application server. The SSL server accepts the connection from the client and sends a connection request to the application server.

   The SSL session is maintained as two separate connections: the connection from the remote client to the SSL server, and the connection from the SSL server to the application server. The intervention of the SSL server is transparent to the client and the application server; to them, it seems that they are communicating directly with each other.

2. Handshake

   After its connection request is accepted, the client initiates a handshake protocol to produce the cryptographic parameters for the session. The SSL server (representing the application server) responds to the handshake and sends the application server's certificate to the client. The SSL server might then ask the client for its client certificate and then attempt to authenticate it.

   Clients that make use of SSL services generally have the certificates associated with the Well Known CAs in their certificate databases. The client compares the signature on the application server's certificate with the appropriate CA certificates to verify the authenticity of the server.

   When the SSL server is requesting client certificates, the CA that signed the client's certificate must be in the SSL server's certificate database. The SSL server can then verify authenticity by comparing the "signature" of the client's certificate with the appropriate CA certificate.

   The client and the SSL server then agree on a protocol version, select cryptographic algorithms (known as cipher suites), and use asymmetric (public-key) encryption techniques to generate shared secrets. From the shared secrets, the SSL server and the client generate the symmetric (private) keys to be used for the encryption and decryption of data sent on the connection.

3. Data transmission

   When the handshake completes, the client sends encrypted data over the network. The SSL server receives the encrypted data from the client, decrypts it, and sends it to the application server. The application server responds by sending unencrypted data to the SSL server. The SSL server receives the unencrypted data from the application server, encrypts it, and sends it to the client.

4. Close

   When a close request is received from either the client or the application server, the SSL server sends a close request to the other party and cleans up the connection.