Performance Issues

It should come as no surprise that data transfer with SSL, on account of all the cryptographic processing, is slower than TCP. Security doesn't come free. Given that, you, an implementer and designer, should understand the extent and nature of this slowness and be able to assess its impact on user experience or response time and system capacity or number of concurrent users. As SSL adds no additional functionality on top of TCP, it is fairly straightforward to get an idea of the overhead by simply running the same program twice, once over TCP and then over SSL. We use a simple benchmark program, consisting of a client and server, to observe the overhead of SSL for making connections and for exchanging messages.

However, you must be careful in interpreting and applying these results to your specific application scenario. Micro-benchmarks, like the one we are going to talk about, tend to execute a small set of operations repeatedly, and suffer from a number of known problems, the most notable being that the benchmark may not simulate a real usage scenario. A real world application does more than just transmit messages and hence the overhead of SSL, although significant with respect to communication time, may be a small percentage of overall processing time. Nevertheless, there is value in understanding the performance trade-offs of basic operations for better system design.

Let us first define our benchmark and the measurement conditions: We measure the performance of SSL and TCP for two different types of activities—exchanging data and establishing connections. The performance of exchanging data over an established connection is measured at the client program by sending 8KB blocks of data to a server program, which acts as a sink, in a loop with an iteration count of 2048, and computing the data transfer rate in MB/second. Similarly, the rate of connection establishment is measured at the client program establishing connection with the server program in a loop and is expressed in terms of connections/second. JSTK utility ssltool was used to simulate client and server programs.

Table 6-1 presents the measured figures for data transfer rate over TCP and SSL connections with different cipher suites under three different scenarios: (I) both client and server programs run on the same machine; (II) client and server program run on different machines connected to a 100 Mbps (Mega bits per second) Ethernet LAN; (III) same as II but with 10 Mbps Ethernet LAN. Both machines were equipped with 450 MHz Pentium II CPU, 256 MB RAM, were running Windows 2000 with Service Pack3, and had J2SDK v1.4 from Sun.

A number of observations are in order:

• The measured TCP data transfer rate for scenarios (II) and (III) is close to the raw bandwidth offered by Ethernet wire. In fact, a popular native benchmarking tool for TCP performance on Windows machines, pcattcp, downloadable from http://www.pcausa.com/Utilities/pcattcp.htm, simulating the same load as our ssltool based benchmark, reported a bandwidth of 11.4 MB/sec and 1.1 MB/sec, respectively, between these two machines. These numbers are close to our observed values of 11.3 and 1.10, respectively.

  Table 6-1. Data transfer rate (MB/second)—TCP and SSL

  Connection Protocol/Cipher Suite	(I)	(II)	(III)
  TCP	11.50	11.3	1.10
  SSL_RSA_WITH_RC4_128_MD5	1.50	3.00	1.00
  SSL_RSA_WITH_RC4_128_SHA	1.20	2.30	1.00
  SSL_RSA_WITH_NULL_MD5	2.85	5.40	1.00
  SSL_RSA_WITH_NULL_SHA	2.80	3.50	1.00
  SSL_RSA_WITH_3DES_EDE_CBC_SHA	0.27	0.55	0.48
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA	0.27	0.55	0.48
  SSL_RSA_WITH_DES_CBC_SHA	0.55	1.14	0.93
  SSL_DHE_DSS_WITH_DES_CBC_SHA	0.55	1.14	0.90

  
  

• The SSL data transfer rate is worse when both client and server are running on the same machine than when they are running on different machines for 100 Mbps LAN. This can be explained by the fact that the benchmark simulates a continuous stream of data flow, allowing parallel cryptographic processing at both the machines.

• As expected, the SSL data transfer rate depends on the cipher suite. In most practical cases, SSL slows the data transfer by 90 to 95 percent for 100 Mbps LAN and by 10 to 50 percent for 10 Mbps LAN. How do we explain this? For 100 Mbps LAN, the CPU is the bottleneck whereas for 10 Mbps LAN, the network bandwidth becomes the bottleneck.

• Cipher suites using MD5 for computing MAC are faster than the corresponding ones using SHA. However, keep in mind that MD5, using 128 bits for hash values, is considerably weaker than SHA, which uses 160 bits for hash values.

Now let us look at connection establishment overhead of SSL under the same scenarios. These performance figures for TCP and certain selected cipher suites are presented in Table 6-2.

The impact of SSL is even more profound on the rate of connection establishment, with DSS-based authentication performing significantly worse than RSA. This is expected, as DSS is much slower than RSA. In fact, now that RSA's patent has expired, there is no valid reason to use DHE and DSS in place of RSA. Other things to notice: network bandwidth plays no role here as the public-key cryptography dominates the overall connection setup time. Also, unlike the data transfer rate, the connection rate is not better for a two-machine scenario. This is only to be expected as the connection setup involves sequential processing by both machines.

In a real application the data transfer rate or connection time alone is rarely of much concern. What you really care about is the response time (how long does it take to satisfy a request?) and the capacity of the system (how many requests can be processed per unit of time?). The impact of SSL on both of these metrics would depend on the structure of a specific application, average load, type of interactions, network latency, specific J2SE platform and many other things besides CPU speed, network bandwidth and transport protocol. Still, the use of SSL could have a significant adverse impact on response time and system capacity. We will talk some more about it in Chapter 8, Web Application Security.

The good news is that this processing can be significantly speeded up by specialized crypto accelerators and separate SSL connections can be processed in parallel on different machines, improving the response time and scaling the capacity.