SSL page access through an SSL junction

In this test case the client has an SSL connection to the WebSEAL server and accessed the Web page on the back end WebSphere® Application Server via an SSL connection (SSL junction).

Using page sizes of 5.8 KB and 12 KB

This test involves two SSL accesses comparing software encryption against hardware encryption. Encryption occurs between the client and WebSEAL on the front end and between WebSEAL and the back end server. We initially tried WebSphere Application Server running on z/OS® as the back end server, however, we were not able to get the WebSphere Application Server to select DES-168 as the cipher suite. To get around this problem, we used the Apache HTTP server under Linux® running on a separate LPAR as the back end server. The DES-168 encryption algorithm was used for encryption operations between the client and WebSEAL and WebSEAL and Apache Web server. In this test only one handshake occurs.

Encryption algorithm: DES-168

Figure 1. 5.8 KB and 12 KB SSL page access through an SSL junction

eseal12

Observations

The improvement of hardware encryption was, again, between 30% and 50%. The degradation of the throughput compared with SSL through a TCP junction (see Figure 1) was about 60%. The CPU load on the WebSEAL system was high, between 80% and 95%.

Conclusion

The WebSEAL server has much more work to do in this scenario, the encrypted packages have to be decrypted, analyzed, and encrypted again. This leads to a significant degradation of the throughput, which could be reduced by using hardware support for encryption. Be aware that the alternative to this overhead, like an isolated network using a HiperSockets™ connection or a z/VM® guest LAN, can be easily implemented on System z™ and produces the same grade of security without this overhead.