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.
When a client requests an SSL connection, the client and the server execute this handshake protocol:
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.
In a fundamental segment of the SSL handshake protocol, the client and server cooperatively determine the details of encryptionincluding 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |