Overview of the SSL Protocol


(EMS uses SSL to secure data in two situations—between a client and a server, and between two servers. To simplify the examples and explanations in this chapter, we’ll focus on the interaction between client and server, although the same framework applies when two servers communicate using SSL.)

The Secure Sockets Layer (SSL) protocol involves a handshake between the initiator (in our examples, a client program) and the target (in our examples, a server).

Figure 16 illustrates the SSL protocol between the client and server.

Figure 16 SSL Protocol

When a client requests an SSL connection, the client and the server execute this handshake protocol:

  1. The client sends an initiating message to the server. This message contains the highest version of SSL and the list of cipher suites the client supports. For more information about cipher suites, see Specifying Cipher Suites.
  2. The server chooses the highest version of SSL and the best cipher suite that both the client and the server support. The server sends this information to the client.
  3. If the client requires that the server authenticate itself (optional), the server sends its digital certificate or certificate chain.
  4. If the server requires that the client authenticate itself (optional), the server sends a request to the client for the client’s digital certificate.
  5. The server then informs the client that it has completed the initial phase of the negotiation.
  6. If the server requested the client’s digital certificate or certificate chain (optional), the client sends it to the server.
  7. The client and server then generate a symmetric encryption key. Client and server use this key to encrypt and decrypt data that they exchange.
  8. If the server requires that the client authenticate itself (optional), the client sends a digital signature to the server. The server decrypts this signature using the client’s public key. If the server successfully decrypts the signature, the server has authenticated the client.
  9. The client informs the server that is ready to communicate secure data.
  10. The client finishes the handshake protocol and can begin sending secure data.
  11. The server informs the client that is ready to communicate secure data.
  12. The server finishes the handshake protocol and can begin sending secure data.

When establishing an SSL connection, several of the steps described above are optional. The client and the server can specify SSL configuration parameters to control the connection steps; see Configuring SSL in the Server and Configuring SSL in EMS Clients.

Cipher Suite Negotiation

In a fundamental segment of the SSL handshake protocol, the client and server cooperatively determine the details of encryption—including cipher algorithms, key sizes, and more. The specification of a particular set of algorithms and key size is known as a cipher suite. Both the client and the server can specify the cipher suites they support. During the SSL handshake, the client and server select the strongest cipher suite that they both support. For more information, see Specifying Cipher Suites.

Client and Server Authentication

In an optional part of the SSL handshake, the client and server authenticate themselves to each other. This step ensures that both parties are communicating with the expected applications.

Server Authentication to the Client

A rogue server could attempt to impersonate your EMS server. To prevent clients from connecting to the rogue server, the client can request that the server present its digital certificate to the client.

During the handshake, the client requests the server’s digital certificate and checks its issuer against the client’s list of trusted certificate authority (CA) certificates. If the CA of the server certificate is not in the client’s list, the client halts communications with that server.

Client Parameters

Connection factories can use the ssl_verify_host parameter to require that the server authenticate itself to the client. The ssl_trusted parameter specifies the CAs that the client trusts. For more information, see Configuring a ConnectionFactory.

EMS servers in a fault-tolerant configuration can use the ft_ssl_verify_host parameter to require that the other server authenticate itself. The ft_ssl_trusted parameter specifies the list of CAs to trust. For more information, see Chapter 13, Fault Tolerance.

Server Parameters

A client may request server authentication. Therefore, the server must specify the ssl_server_identity parameter, and (if the password is not part of the server’s digital certificate) the ssl_password parameter. For more information, see SSL Server Parameters.

Verifying the Server’s Hostname

You can configure an EMS client to verify the server’s hostname. During the handshake, the client checks the CN field of the server certificate against the name of the connected host, or if an expected hostname is provided, against that name. If the names do not match, the client rejects the connection.

Client Parameters

Connection factories can use the ssl_verify_hostname and ssl_expected_hostname parameters to require verification of the hostname in the server’s digital certificate. For more information, see Configuring a ConnectionFactory.

EMS servers in a fault-tolerant configuration can use the ft_ssl_verify_hostname and ft_ssl_expected_hostname parameters to require verification of the other server’s hostname. For more information, see Chapter 13, Fault Tolerance.

Client Authentication to the Server

In many applications, the server accepts connections from any client, so server authentication is not needed. However, client passwords can be compromised, so certificate authentication is a stronger check to verify the identity of clients. To prevent rogue clients from logging into the server, the server can request that the client present its digital certificate to the server.

During the handshake, the server requests the client’s digital certificate and checks its issuer against the server’s list of trusted CAs. If the CA of the client certificate is not in the server’s list, the server halts further communications with that client.

Server Parameters

To require that clients authenticate themselves the EMS server must specify true for the ssl_require_client_cert parameter. The ssl_server_trusted parameter specifies the CAs the server trusts. For more information, see SSL Server Parameters.

Client Parameters

Connection factories can specify their client identities using the ssl_identity parameter, and (if the password is not part of the client’s digital certificate) the ssl_password parameter. For more information, see Configuring a ConnectionFactory.

Retrieving the Username from the Client’s Digital Certificate

The EMS server can extract the client's username from the client's digital certificate, and authorize it against permissions in an access control list (ACL). (Note that this type of authorization differs in intent from SSL authentication; see Chapter 9, Authentication and Permissions.) If authorization is enabled, the server checks client permissions keyed to the username in the client’s digital certificate. If the ACL requires a password, the client must provide the password when creating the connection object.

Server Parameters

To instruct clients to login using the usernames from their digital certificates, the EMS server must specify true for the ssl_use_cert_username parameter in tibemsd.conf. For more information, see SSL Server Parameters.

Using a Special User Name to Log In

The EMS server can recognize one special username; when a client logs in with that username, the server authorizes the client with the username taken from the client’s digital certificate.

Server Parameters

To configure this behavior, set the ssl_cert_user_specname parameter in tibemsd.conf. For more information, see SSL Server Parameters.


TIBCO Enterprise Message Service™ User’s Guide
Software Release 4.3, February 2006
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com