Java 1.5 SR 9 JSSE SSL logon method comparison

Edit online

JSSE SSL logon methods were compared using Java™ 1.5 SR 9.

It is interesting to compare different SSL logon methods, to examine the throughput and resource requirements of SSL handshakes and client authentication. Three different logon methods are explored:
  • Client authentication
  • Cached - where SSL sessions are not invalidated and therefore are cached
  • Uncached - where the SSL session is invalidated.

    This method is used in all the other studies of this paper, because it forces a new SSL handshake when each new session is created.

Client authentication data using the hardware are not available in this study. For client authentication, the SSL sessions are also uncached. For these studies, the packet size is 1 byte, in order to minimize the effects of bulk data encryption.

The results are summarized in tabular format in Results tables, tables Table 7 and Table 8.

The results are displayed graphically in Figure 1 and Figure 2. Because the throughput values for the different cipher suites are close, only CPU utilization results are displayed.

Figure 1. Java 1.5 SR 9 JSSE SSL logon method comparison: Cached and uncached, JSSE server using cryptographic hardware and software
%CPU Utilization - Cached and uncached, JSSE server, hardware and software
Figure 2. Java 1.5 SR 9 JSSE SSL logon method comparison: Cached and uncached, JSSE client using cryptographic hardware and software
%CPU Utilization - Cached and uncached, JSSE client, hardware and software

Observations

Client authentication using software encryption requires 40% or more additional CPU resources on the JSSE client. Client authentication also reduces throughput slightly, at least when running in software.

Cached SSL sessions save approximately half of the CPU resources on the JSSE server, when running with software encryption, with little or no change on the client side. Running on the cryptographic hardware, the cached SSL sessions have a CPU load approximately 16% on both the client and the server, except for cipher RC4-128, where it is approximately 6% on both. Caching the sessions almost doubles the throughput, whether running with hardware or software encryption. The throughput for cached sessions with hardware or software encryption are equivalent.

Comparing uncached sessions with hardware and software encryption, there is a significant CPU savings on the server when using cryptographic hardware instead of software. While there is a 3% increase in CPU load on the client, there is approximately a 32% CPU savings on the server (36% for cipher RC4-128). The throughput for uncached sessions with 1 byte packet sizes is slightly lower on hardware than on software.

Conclusions

Client authentication running with software encryption requires significantly more CPU resources on the client because the additional keys in the certificate presented by the client require CPU-intensive operations on the client.

When running with software encryption, the 30% to 35% savings in CPU resources using cached SSL sessions probably represent the typical cost of running the SSL handshakes in the Java software stack. Cached sessions have nearly double the throughput of uncached sessions with either hardware or software encryption. This shows that caching the SSL information is a very effective way to improve throughput and reduce CPU utilization.

For the uncached sessions, the throughput is slightly lower with cryptographic hardware encryption compared to software encryption for the 1 byte packets. This is consistent again with the cost of using the cryptographic hardware for packets of a trivial size. Using very small packets does not demonstrate the strength of the cryptographic hardware, but the small reduction in throughput with 1 byte packets still shows a minimum of 28% savings in overall CPU utilization.