Transport Layer Security (TLS) for IP connections

TLS is a cryptographic protocol that provides security for connections over the Internet Protocol network. It is used for sessions over the web and for IPIC sessions. In both cases, the concept exists of a client that initiates a request and a server that provides the response. CICS® can operate as a client or a server. A TLS session has two protocols: a handshake protocol to establish a secret key and a record protocol to encrypt data that flows in the session.

TLS is the modern version of a protocol originally called Secure Sockets Layer (SSL). SSL protocols are no longer supported, but the term is sometimes used interchangeably with TLS, especially in API options and resource definitions.

The TLS handshake is for the client and server to agree characteristics about the session: the TLS protocol and a cipher. The protocol that is used is the highest level that is supported by both sides. The cipher that is selected is a cipher that is common to both sides. The cipher that is selected is the first one in the list that is supplied by the server. If no common protocol or cipher is identified, a connection cannot be made. The exact mechanism of the handshake depends on the protocol level. Figure 1 and Figure 2 show how the configurable parameters flow between the client and the server.

For a more in-depth view of the TLS protocol, including keys and message authenticate codes (MACs), see TLS 1.2 Protocol and TLS 1.3 Protocol in the IBM SDK Java Technology Edition documentation.

Flow of the TLS 1.2 handshake

Figure 1 is a swimlane diagram that shows the flow of the TLS 1.2 handshake.

Figure 1. The TLS 1.2 handshake
A swimlane diagram showing the TLS handshake between a client and server in case of TLS 1.2
An explanation of each step in Figure 1 follows:
  1. The client:
    • Sends the highest version of TLS that it supports.
    • Sends a list of the cipher suites that it supports.
  2. The server:
    • Chooses the highest version of TLS that both the client and server support.
    • Chooses the best cipher suite that both the client and server support.
    • Sends agreed TLS version and cipher suite.
    • Sends a server certificate.

      Optionally, requests a client certificate.

      Important: Part of the handshake is the exchange of digital certificates. A digital certificate for the server is passed to the client. The client knows that the server can be trusted according to which certificate authority (CA) signed the server certificate. If the CA is trusted, the server certificate is trusted and the TLS session is set up. The server might use a certificate from the client to identify the client. Certificates are part of the authentication process rather than confidentiality so are covered in Certificates.
  3. The client validates the server certificate, and optionally, sends the client certificate.
  4. The server:
    • Validates the client certificate, if sent.
    • Sends a session setup message.
  5. Start of secure communication of data.
  6. Communication continues securely.

Flow of the TLS 1.3 handshake

Figure 2 a swimlane diagram that shows the flow of the TLS 1.3 handshake.

Figure 2. The TLS 1.3 handshake
A swimlane diagram showing the TLS handshake between a client and server in case of TLS 1.3
An explanation of each step in Figure 2 follows:
  1. The client:
    • Sends the highest version of TLS that it supports.
    • Sends a list of the cipher suites that it supports.
    • Sends a list of key share groups it supports.
  2. The server:
    • Chooses the highest version of TLS that both the client and server support.
    • Chooses the best cipher suite that both the client and server support.
    • Chooses the key share groups that both the client and the server support based on the client's preference settings.
    • Sends agreed TLS version and cipher suite.
    • Sends a server certificate.

      Optionally, requests a client certificate.

      Important: Part of the handshake is the exchange of digital certificates. A digital certificate for the server is passed to the client. The client knows that the server can be trusted according to which certificate authority (CA) signed the server certificate. If the CA is trusted, the server certificate is trusted and the TLS session is set up. The server might use a certificate from the client to identify the client. Certificates are part of the authentication process rather than confidentiality so are covered in Certificates.
  3. The client:
    • Validates the server certificate.

      Optionally, sends the client certificate.

    • Start of secure communication of data.
  4. The server:
    • Validates the client certificate, if sent.
    • Communication continues securely.