15.9 Tuning SSL/TLS-Related Settings

This section contains the following topics:

Section 15.9.1, "SSL/TLS Session Caching"
Section 15.9.2, "Ciphers and Certificate Keys"

15.9.1 SSL/TLS Session Caching

During the initial SSL/TLS handshake process for an HTTPS connection, the client and server negotiate the cipher suites to be used, and the encryption/decryption and MAC keys (see "About SSL"). This activity requires significant CPU time, depending on whether RSA or ECC private keys are used, and the size of the keys.

The initial SSL/TLS handshake results in the generation of a unique SSL/TLS session ID. If the SSL/TLS session ID is cached, then the next time that same HTTPS client opens a new socket connection, the server can reduce the time taken to establish the connection by retrieving the SSL/TLS session ID from the cache and performing an abbreviated SSL/TLS handshake, which is less CPU-intensive than the initial handshake.

SSL/TLS session caching is enabled by default in Oracle Traffic Director. When a new connection is established on an SSL/TLS-enabled listener, Oracle Traffic Director checks whether the SSL/TLS session cache contains a session ID for the client. If the session ID for the client exists in the cache and is valid, Oracle Traffic Director allows the client to reuse the session.

You can configure the maximum number of entries in the SSL/TLS session cache and the duration for which SSL/TLS session IDs should be stored in the cache.

You can configure the SSL/TLS session cache settings for a configuration by using either the administration console or the CLI.

Configuring SSL/TLS Session Cache Settings Using the Administration Console

To configure SSL/TLS session cache settings by using the administration console, do the following:

Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.

A list of the available configurations is displayed.
Select the configuration that you want to modify.
In the navigation pane, select SSL.

The SSL Settings page is displayed.
Go to the SSL & TLS section on the page.
Specify the parameters that you want to change.

On-screen help and prompts are provided for all of the parameters.

When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.

At any time, you can discard the changes by clicking the Reset button.
After making the required changes, click Save.
- A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.
- In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."

Configuring SSL/TLS Session Caching Settings Using the CLI

To view the current SSL/TLS caching settings for a configuration, run the get-ssl-session-cache-prop command, as shown in the following example:
```
tadm> get-ssl-session-cache-prop --config=test
max-ssl3-tls-session-age=86400
enabled=true
max-entries=10000
```
To change the SSL/TLS session caching settings, run the set-ssl-session-cache-prop command.

For example, the following command changes the maximum number of entries allowed in the SSL/TLS session cache to 20000.
```
tadm> set-ssl-session-cache-prop --config=soa max-entries=20000
OTD-70201 Command 'set-ssl-session-cache-prop' ran successfully.
```
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.

For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help option.

15.9.2 Ciphers and Certificate Keys

Strong ciphers and large private keys provide better security for SSL/TLS connections, but they affect performance.

In SSL/TLS connections, certain ciphers—such as AES and RC4—require less computing resources for the data transfer than stronger ciphers such as 3DES. Consider this factor when you select SSL/TLS ciphers for listeners for which Strict SNI Host Matching is enabled.

For information about configuring ciphers for listeners, see Section 11.2.4, "Configuring SSL/TLS Ciphers for a Listener."

For information about SNI host matching, see Section 11.2.6, "About Strict SNI Host Matching."
The initial SSL/TLS handshake process takes less time for RSA certificates with small key sizes—1024 and 2048 bits—than for certificates with large key sizes—3072 and 4096 bits.

For information about creating self-signed certificates and certificate-signing requests, see Section 11.4, "Managing Certificates."