Once the handshake process has completed, the same number of packets is exchanged between the connection partners, although CPU cycles are required at both ends to encrypt and decrypt the messages. Some caching storage is available with z/OS secure sockets implementation to reduce the overhead. Initial tests have shown that SSL connections do not generate a significant increase in overhead when compared with their non-SSL equivalent connections.
If the mainframe on which your application is running has cryptographic hardware features and the Integrated Cryptographic Service Facility (ICSF) has been started, the encryption/decryption will be performed on hardware rather than software, improving performance and reducing CPU cycles. The secure sockets application does not have to be changed to use the hardware if it is present.
DEVELOPING YOUR OWN SSL APPLICATIONS
Developing your own SSL applications is possible using the System SSL Programming Interfaces provided with z/OS. Interfaces are only provided for C/C++ and Java applications. Applications written in other languages, such as Assembler, could potentially drive the SSL/TLS functions, but would have to cope with the complications of being compatible with Language Environment (LE) and the differences in program linkage and parameter passing.
As a result, existing sockets applications written to the OE callable services must effectively be rewritten to drive the secure sockets application interfaces. Applications written using the pre-z/OS 1.2 Application Programming Interface (API) will operate on z/OS 1.2 and above, but cannot support TLS Version 1. To support TLS Version 1, applications need to be redeveloped (maybe for a second time) to the new SSL API available from z/OS Version 1.2.
Secure sockets protocols offer an additional level of security not available with IPSec or firewall technologies. This article has introduced secure socket protocols but has by no means covered all of the details required to fully understand and implement an effective security policy.
Implementing secure sockets protocols on z/OS systems is, in principle, relatively easy, but in practice is likely to be fairly complex and time-consuming. The ease of use of SSL between Web servers and browsers should not be used as a benchmark for implementing SSL in other applications. Generally, encryption is the only part of the protocol implemented by Web servers, whereas full security based on secure sockets requires requesting, issuing, and installing digital certificates for all client and server applications. Server certificates may potentially need to be manually installed on all client systems, while all certificates that identify client systems or users may need to be installed on the server system.
However, the benefits to be gained by the use of secure sockets are significant. The server can be certain of the identity of the client application and, equally important (to the client), the client can be certain of the identity of the server. No system utility or intermediate router or LAN-based sniffer can read the data on a secure connection once it has left the application process. The data on a secure connection cannot be modified without the application’s knowledge. With security now a much higher priority worldwide, the implementation of secure sockets on z/OS should allow security managers to sleep more easily. Z