000019873 - Where are the SSL session keys generated and stored?

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000019873
Applies ToRSA ClearTrust 4.7.1 Authorization Server (AServer)
RSA ClearTrust 4.7 Authorization Server (AServer)
RSA ClearTrust 4.7.1
RSA ClearTrust 4.7
IssueClearTrust: Where are the SSL session keys generated and stored?
Where are session keys generated and stored when using anonymous or authenticated SSL for ClearTrust communications?
SSL handshake process
CauseThe following is a summary of pages 33 to 35 of the "RSA ClearTrust 4.7.1 - Overview Guide":
RSA ClearTrust allows you to configure different types of inter-component security between the various components. This includes:
1. No encryption (or cleartext)
2. Shared secret (or symmetric) encryption
3. Anonymous SSL. All data exchanged between ClearTrust components can be encrypted using Secure Sockets Layer (SSL) encryption technology. Before transmission over the network, the data is encrypted using anonymous SSL. Anonymous SSL means that neither the client nor the server is required to present a certificate to authenticate itself.
4. Mutually authenticated SSL. In this mode, each ClearTrust component must present its digital certificate when contacting another component, allowing that component to verify its identity.
In a purely technical sense, all SSL connections require at least the server to be authenticated. In order to address this requirement when using what in ClearTrust terminology is called "Anonymous SSL", the ClearTrust installation deploys a CA certificate and a server certificate for the ClearTrust components, thus, avoiding the burden of configuring the SSL certificates. It follows that the Anonymous SSL does authenticate the server components using a "dummy" certificate, but does not authenticate the client components.
Resolution

The following procedure summarizes the SSL handshake process:
1. Client opens a connection to the server and starts the negotiation of the protocol
2. The server sends its SSL certificate to the client
3. The client generates a session key
4. The client encrypts the session key using the public key of the server (contained in the server's certificate)
5. The client transmits the session key to the server
6. The server uses its secret key (associated to its certificate) to decrypt the session key
7. The server and the client can start communicating through the SSL cryptographic tunnel - given that BOTH now have an identical copy of the session key

NOTE 1: Even in a "Mutually authenticated SSL" session, the client generates the session key

NOTE 2: The above procedure is over-simplified. Consult Netscape?s SSL specification or the RFCs of the Transport Layer Security (the Internet standard version of SSL).

NOTE 3: The following table lists some of the connections of a ClearTrust environment that can be enabled either for anonymous or authenticated SSL:

Client component

Server component 

Port

Entitlements server

Authorization server

auth_port (5615)

Entitlements server

Dispatcher

list_port (5608)

Authorization server

Dispatcher

reg_port (5607)

Key Server

Key Server

election_port (5609)

Web Server Agent

Authorization server

auth_port (5615)

Runtime API clients

Authorization server

auth_port (5615)



 

Legacy Article IDa12943

Attachments

    Outcomes