Secure sockets support was introduced in OS/390 V2.6. Support for SSL protocols has been enhanced over the years with SSL V2 and V3 supported by all current versions of OS/390 and z/OS, and TLS V1 being supported by z/OS V1.2 and above.
Several IBM applications support SSL/TLS protocols, including the TN3270E Server, the FTP Server, the FTP Client, WebSphere Application Server (WAS), and the HTTP Servers.
TN3270E is perhaps the easiest place to start when implementing secure sockets for the first time. Support is enabled by the SECUREPORT and CONNTYPE SECURE keywords in the TCP/IP profile. It is common to add a new secure TN3270E port rather than replace the existing port to allow support for both secure and non-secure connections. The KEYRING keyword is used to define the repository and type of digital certificate database to be used and the CLIENTAUTH keyword determines whether a valid client certificate is mandatory. Users connecting to the secure TN3270E port must be using an SSL-capable TN3270 client (such as IBM’s Personal Communications, IBM’s Host on Demand, and Jolly Giant’s QWS3270 Secure).
The FTP Server and FTP Client support SSL/TLS to further secure and encrypt file transfers. Support is enabled using the EXTENSION AUTH_TLS keywords in the FTPDATA member. Additional keywords are supported to control the level of authentication required and to identify the digital certificate repository. FTP can allow both secure and insecure transfers on the same server, depending on the value of the SECURE_FTP keyword. The FTP protocol requires some additional consideration when implementing secure sockets. Both the control and data FTP connections are encrypted, providing a high level of security but at the same time potentially disabling some firewall functionality. The FTP protocol passes IP addresses in the data transmission and some firewalls parse this data, verifying and often converting the IP addresses for Network Address Translation (NAT). As the FTP control session is encrypted, and the firewall cannot decrypt the data, NAT and the subsequent file transfer will fail. This is a recognized limitation and extensions to the FTP protocol have been implemented to cope with this problem and will be available in a future release of z/OS.
The HTTP Server and WAS support secure socket communications for the more traditional use of SSL, Web serving. The HTTPS (HTTP + SSL) protocol typically uses port 443 (instead of the HTTP port 80) to implement secure sockets over the HTTP protocol. The WAS supports SSL for communications with other SSL-capable components and clients.
COMMUNICATING WITH NON-z/OS APPLICATIONS
Secure sockets can, of course, be used for communications between z/OS systems and SSL-enabled clients (i.e., TN3270E and FTP) and the respective z/OS-based servers. As SSL/TLS are documented protocols, other operating system platforms and applications can implement secure sockets and communicate with z/OS-based applications.
As discussed previously, following the establishment of a connection, a security handshake takes place. Part of this handshake includes the exchange of the level of SSL/TLS and the encryption algorithms that are supported and acceptable to both partners. The application can usually define the order in which the supported options are negotiated. The handshake is successful when a specific level of SSL/TLS and encryption algorithms are supported by both applications. If no common set is found, the handshake process fails, and the applications cannot implement a secured connection.
The implementation of secure sockets does have some performance implications. After connection establishment, but prior to data exchange, the handshake protocol does require the exchange of a series of encrypted messages, leading to a small delay before the first data packet is seen. For protocols such as TN3270E, this could mean the initial sign-on screen seen by the user takes a little longer to be displayed.