SSL protection is initiated when a secure connection request is sent from one machine to another--for example, when a browser sends a request to a surrogate proxy server. The request syntax https:// instead of http:// tells the browser to send the request on port 443, which is where the server listens for secure connection requests (instead of port 80 for routine requests). To establish a secure session between the browser and the server, the two machines perform an exchange called an SSL handshake to agree on a cipher specification and to select a key that is used to encrypt and decrypt information. Keys are automatically generated, and they expire when the session expires. A typical scenario (assuming SSL Version 3) is the following:
The client initiates an SSL session with Caching Proxy by sending a Client Hello message that describes the client's encryption capabilities.
The server sends its certificate to the client and chooses the ciphersuite to use for data encryption.
The client sends cipher key information that is used to create symmetric encryption keys for the encrypted data. This key material is known as the premaster secret and it is encrypted with the server's public key (obtained from the server's certificate; see Key and certificate management). Both the server and the client can derive the read and write symmetric encryption keys from the pre-master secret.
The server sends a final confirmation and a Message Authentication Code (MAC) for the entire handshake protocol.
The client sends a message to validate the server finish message.
If the client validates the server finish message, then encrypted data flow begins.
Using a Caching Proxy as an end point for secure connections can reduce the load on your content or application servers. When a Caching Proxy maintains a secure connection, it performs encryption, decryption, and key creation, which are all CPU-intensive operations. Caching Proxy also allows you to configure SSL session timeouts to maximize the use of each key.
Limitations of SSL
The following limitations apply to SSL in WebSphere® Application Server's Caching Proxy:
During high HTTPS traffic volumes, the Caching Proxy server might cause high CPU usage. Tuning changes to an environment variable (GSK_V3_SIDCACHE_SIZE) and a proxy directive (SSLV3Timeout) can help the proxy server handle the load and reduce the CPU usage.
The SSL session ID identifies reusable SSL sessions, including encryption or decryption keys used by both browsers and servers, and is used to avoid unnecessary SSL handshakes on new connections, which consume a lot of the server's CPU time. The GSKit library for the Caching Proxy server supports SSL session ID and includes an SSL session ID cache. By default, the SSL session ID cache contains 512 entries. When the entry limit is reached, the oldest session entry will be removed and the new entry will be added into the cache.
Use the GSK_V3_SIDCACHE_SIZE environment variable to change the default size of the SSL session ID cache. A valid value of the variable is between 1 and 4096. Increasing the size will increase the look-up time required to locate a cached SSL session. However, the increased look-up time is insignificant compared to the overhead required to establish an SSL connection. Increasing the cache size will help the proxy server handle more concurrent SSL sessions and reduce the CPU usage when the proxy server is under high HTTPS loads.
Caching Proxy also has a tunable directive SSLV3Timeout. (See SSLV3Timeout -- Specify the time to wait before a SSLV3 session expires.) The default value of the directive is 1000 seconds. This directive defines the lifetime of an SSL session in the session cache. If no incoming SSL connection uses an existing SSL session and the session lifetime exceeds the value, that session will be removed from the session cache. It is recommended to set the SSLV3Timeout value to the length of a typical secured client session. If the timeout is set too short, it may slow the performance of the proxy because multiple SSL handshake sessions are needed to complete a single secured session. However, if the value is set too long, it may also hurt the security of a secured session.