Secure Sockets Layer performance tips
Use this page to learn about Secure Sockets Layer (SSL) performance tips. Be sure to consider that performance issues typically involve trade-offs between function and speed. Usually, the more function and the more processing that are involved, the slower the performance.
- Handshake
- Bulk encryption and decryption
When an SSL connection is established, an SSL handshake occurs.When a connection is made, SSL performs bulk encryption and decryption for each read/write. The performance cost of an SSL handshake is much larger than that of bulk encryption and decryption.
To enhance SSL performance, decrease the number of individual SSL connections and handshakes.
Decreasing the number of connections increases performance for secure communication through SSL connections, as well as non-secure communication through simple Transmission Control Protocol/Internet Protocol (TCP/IP) connections. One way to decrease individual SSL connections is to use a browser that supports HTTP 1.1. Decreasing individual SSL connections can be impossible if you cannot upgrade to HTTP 1.1.
- Verify that the maximum number of keep alives are, at minimum, as large as the maximum number of
requests per thread of the web server (or maximum number of processes for IBM® HTTP Server on UNIX). Make sure that the web server
plug-in is capable of obtaining a keep alive connection for every possible concurrent connection to
the application server. Otherwise, the application server closes the connection when a single
request is processed. Also, the maximum number of threads in the web container thread pool should be
larger than the maximum number of keep alives, to prevent the keep alive connections from consuming
the web container threads.Note: HTTP Transports have been deprecated. For instructions on how to set a maximum keep alive value for channel-based configurations, see HTTP transport channel settings
- Increase the maximum number of requests per keep alive connection. The default value is 100, which means the application server closes the connection from the plug-in following 100 requests. The plug-in then must open a new connection. The purpose of this parameter is to prevent denial of service attacks when connecting to the application server and preventing continuous send requests to tie up threads in the application server.
- Use a hardware accelerator if the system performs several SSL handshakes.
Hardware accelerators that are currently supported by the WebSphere Application Server increase the SSL handshake performance, not the bulk encryption, and decryption. An accelerator typically benefits the web server because web server connections are short-lived. All other SSL connections in WebSphere Application Server are long-lived.
The IBM Cryptographic Coprocessor is not supported for use with WebSphere Application Server. However, you can use the IBM Cryptographic Coprocessor to improve SSL performance for other products, such as IBM HTTP Server for iSeries, which is powered by Apache.
- Use an alternative cipher suite with better performance.
The performance of a cipher suite is different from software and hardware. Just because a cipher suite performs better in software does not mean that a cipher suite will perform better with hardware. Some algorithms are typically inefficient in hardware, for example, Data Encryption Standard (DES) and triple-strength DES (3DES); however, specialized hardware can provide efficient implementations of these same algorithms.
The performance of bulk encryption and decryption is affected by the cipher suite that is used for an individual SSL connection. The following chart displays the performance of each cipher suite. The test software calculating the data was Java™ Secure Socket Extension (JSSE) for both the client and server software, which used no cryptographic hardware support. The test did not include the time to establish a connection, but only the time to transmit data through an established connection. Therefore, the data reveals the relative SSL performance of various cipher suites for long running connections.
Before establishing a connection, the client enables a single cipher suite for each test case. After the connection is established, the client times how long it takes to write an integer to the server and for the server to write the specified number of bytes back to the client. Varying the amount of data had negligible effects on the relative performance of the cipher suites.
- Bulk encryption performance is only affected by what follows the
WITH
in the cipher suite name because the portion preceding theWITH
identifies the algorithm that is used only during the SSL handshake. MD5
and Secure Hash AlgorithmSHA
are the two hash algorithms that are used to provide data integrity.MD5
is generally faster thanSHA
, however,SHA
is more secure thanMD5
.DES
andRC2
are slower thanRC4
. TripleDES
is the most secure, but the performance cost is high when using only software.- The cipher suite providing the best performance while still providing privacy is
SSL_RSA_WITH_RC4_128_MD5
. Even thoughSSL_RSA_EXPORT_WITH_RC4_40_MD5
is cryptographically weaker thanRSA_WITH_RC4_128_MD5
, the performance for bulk encryption is the same. Therefore, as long as the SSL connection is a long-running connection, the difference in the performance of high, and medium security levels is negligible. It is recommended that a security level of high be used, instead of medium, for all components participating in communication only among WebSphere Application Server products. Make sure that the connections are long running connections.