Secure Sockets Layer (SSL) is a system that automatically encrypts information before sending it over the Internet and decrypts it at the other end before it is used. This protects sensitive information like credit card numbers while it is transmitted over the Internet.
Caching Proxy uses SSL to secure surrogate servers and to provide secure remote administration, as described in the following sections. SSL can also be used to protect connections to back-end servers (for example, content or application servers) as well as to protect communications between the proxy server and its clients.
For forward proxy, Caching Proxy supports SSL tunneling, which bypasses SSL and forwards the already-encrypted data without altering it.
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.
This applies to forward proxy configurations only.
When Caching Proxy is configured as a forward proxy, it uses SSL tunneling to support secure connections between clients and content servers. In SSL tunneling, encrypted data is passed through the proxy server unaltered. Because the proxy server does not unencrypt the data, functions that require the proxy server to read requests or document headers are not supported in SSL tunneling. Also, tunneled requests are not cached.
Figure 2 shows how a connection is established by using SSL tunneling.
The SSL tunneling process is as follows:
In a forward proxy setting, only SSL tunneling is available. To enable SSL tunneling, in the Configuration and Administration forms, select Proxy Configuration -> Proxy Settings. Select the SSL Tunneling check box.
The CONNECT method (which by default is disabled) must also be enabled for SSL tunneling connections. To enable this in the configuration forms, select Server Configuration -> Request Processing and use the HTTP Methods form.
Three options (OutgoingPorts, OutgoingIPs, IncomingIPs) are provided for the Enable CONNECT directive for enhanced SSL tunneling security. It is required that you specify a value for at least OutgoingPorts, otherwise the CONNECT method will not be enabled.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]To allow clients to connect only to the remote servers' port 443 for SSL tunneling, set the following directives. (Normally port 443 is for HTTPS requests on the remote server.)
Enable CONNECT OutgoingPorts 443 SSLTunneling onTo allow clients to connect to any port on the remote servers for SSL tunneling, set the following directives:
Enable CONNECT OutgoingPorts all SSLTunneling onTo allow clients to connect to ports 80, 8080-8088, and 9000 and above ports on the remote servers for SSL tunneling, set the following directives:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
Ports and port ranges are separated by a comma without any space in the list.
IMPORTANT: For forward proxy configurations, at least specify 443 or all with OutgoingPorts option to enable normal SSL tunneling.
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]For example, to allow clients to connect to any port on the remote servers that matches the IP/host name *.ibm.com and must not match 192.168.*.* , set the following directives:
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP_Pattern,...]For example, to allow clients coming from IP address 192.168.*.* to make a connection to any port on the remote servers for SSL tunneling, set the following directives:
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
For more information to enable SSL tunneling and the CONNECT directives by editing the proxy configuration file, see the reference sections in Appendix B. Configuration file directives for the following directives:
Remote administration of your Caching Proxy can be achieved by using the security features provided by Secure Sockets Layer (SSL) and password authentication. This significantly reduces the probability of access to the proxy server by unauthorized persons.
To apply SSL during remote administration of your server, use an https:// request instead of an http:// request to open the Configuration and Administration forms. For example:
https://your.server.name/yourFrontPage.html
As noted previously, before configuring SSL you must set up a key database and obtain or create a certificate. Certificates are used to authenticate server identities. Use the IBM Key Management utility (sometimes called iKeyman) to set up your certification files. This utility is part of the GSKit software, which is included with Application Server. GSKit also includes a Java-based graphical interface for opening certificate files.
The following are the basic steps to set up your SSL keys and certificates.
On all operating systems except for Linux, if the certificate has expired, Caching Proxy will not start properly, and an error message will display indicating the key database has expired. On Linux, the proxy appears to start but the process quickly disappears and no error message gets generated.
To prevent this problem on Red Hat Enterprise Linux 3.0 systems, ensure that the GCC packages are at the following levels or higher:
Your public key must be associated with a digitally signed certificate from a certificate authority (CA) that is designated as a trusted root CA on your server. You can buy a signed certificate by submitting a certificate request to a certificate authority (CA) provider. Caching Proxy supports the following external CAs:
By default, the following are designated as trusted CAs:
This section provides a quick reference for using the IBM Key Manager utility (iKeyman). Use the key manager to create your SSL key database file, public-private key pair, and certificate request. After you receive the CA-signed certificate, use the key manager to place the certificate in the key database where you created the original certificate request.
More detailed documentation on the IBM Key Manager and GSKit is packaged with the GSKit software.
Set up your system to run the key manager
Before starting the IKeyman GUI, do the following:
On Windows:
set JAVA_HOME=C:\Program Files\IBM\edge\lb\java
On Linux and UNIX:
export JAVA_HOME=/usr/opt/IBM/edge/lb/java
On Windows:
set JAVA_HOME=%WAS_ROOT%\java
On Linux and UNIX:
export JAVA_HOME=/$WAS_ROOT/java
Starting the key manager
Start the key manager graphical user interface as follows:
Note that if you create a new key database file during this session, the file is stored in the directory from which you started the key manager.
A key database is a file that the server uses to store one or more key pairs and certificates. You can use one key database for all your key pairs and certificates, or create multiple databases. The key management utility is used to create new key databases and specify their passwords and stash files.
To create a key database and stash file:
The password that you specify when you create a new key database protects the private key. The private key is the only key that can sign documents or decrypt messages encrypted with the public key.
Use the following guidelines when specifying the password:
It is a good practice to change the key database password frequently. However, if you specify an expiration date for the password, keep a record of when to change it. If the password expires before you change it, a message is written to the error log and the server starts, but it cannot make secure network connections.
Follow these steps to change the key database password:
For an SSL connection between a proxy and an LDAP server, put the key database password in the pac_keyring.pwd file. (Note that the pac_keyring.pwd file is not the stash file generated by IKeyMan.)
Creating a new key pair and certificate request
The key database stores key pairs and certificate requests. To create a public-private key pair and certificate request, follow these steps:
A new certificate request has been successfully created in the file keyfile_database_name.
Creating a self-signed certificate
Use the key management utility to create a self-signed server certificate to enable SSL sessions between clients and your proxy server while waiting for a certificate to be issued. You also can use self-signed certificates for testing purposes.
Follow this procedure to create a self-signed certificate:
Exporting keys
Use this procedure to export keys to another key database:
Importing keys
To import keys from another key database:
Listing certificate authorities
To display a list of trusted certificate authorities (CAs) in a key database:
Use this procedure to receive a certificate that is electronically mailed to you from a certificate authority (CA) that is designated as a trusted CA by default (see the list in Certificate authorities). If the CA that issues your CA-signed certificate is not a trusted CA in the key database, you must first store the CA's certificate and designate the CA as a trusted CA. Then you can receive your CA-signed certificate into the database. You cannot receive a CA-signed certificate from a CA that is not a trusted CA (see Storing a CA certificate).
To receive a CA-signed certificate into a key database:
Only certificates signed by trusted CAs are accepted for establishing secure connections. To add a CA to the list of trusted authorities, you must obtain and store its certificate as trusted. Follow this procedure to store a certificate from a new CA, prior to receiving it into the database:
Displaying the default key in a key database
Display the default key entry as follows:
The encryption algorithms and hashes used for SSL versions 2 and 3 are listed in the following tables.
Key Pair Generation: RSA 512-1024 private key sizes
SSL Version 2
US version | Export version |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56-bit | not applicable |
Triple DES US | not applicable |
RC4 Export | not applicable |
RC2 Export | not applicable |
SSL Version 3
US version | Export version |
Triple DES SHA US | DES SHA Export |
DES SHA Export | RC2 MD5 Export |
RC2 MD5 Export | RC4 MD5 Export |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 Export | NULL NULL |
RC4 SHA 56-bit | not applicable |
DES CBC SHA | not applicable |
NULL SHA | not applicable |
NULL MD5 | not applicable |
NULL NULL | not applicable |
These SSL specifications can also be configured by directly editing the proxy configuration file. For details, see the reference sections in Appendix B. Configuration file directives for the following directives:
128-bit encryption for Caching Proxy
Only a 128-bit encryption version of Caching Proxy is being delivered. The 56-bit version is no longer available. If you are updating a previous version, you can install Caching Proxy directly to your currently installed 128-bit or 56-bit version. If you were previously using a 56-bit (export) browser, you must upgrade to a 128-bit browser in order to take advantage of the 128-bit encryption in the proxy.
After an upgrade from a 56-bit version of Caching Proxy to the 128-bit version, if the key size used to encrypt certificates is set to 1024, then no configuration change is necessary. However, if the key size is set to 512, in order to take advantage of the proxy's 128-bit encryption, you must create new certificates with a key size of 1024. Create new keys by using the IBM Key Manager utility (iKeyman).
See Key and certificate management for a detailed discussion of the IBM Key Manager utility.
Note that this version of the product does not support encryption on SUSE Linux.