AT-TLS for the Modern Mainframe Java Applications
This article offers an overview of the purpose and use of the AT-TLS, a z/OS Communication Server component, in Java applications on the mainframe. AT-TLS (Application Transparent — Transport Layer Security), also known as just TTLS (the original name), is a layer in z/OS Communication Server that can enable the use of HTTPS protocol for any application. Broadcom has invested significant R&D time in exploring the topic and even contributed a Java library to the Zowe project where we share the expertise we gained on this topic.
In essence, an HTTP or FTP application could be written without supporting the security version of the protocols and leave it to the operating system to upgrade it with the secured extension. This results in having just one layer and one definition of security parameters for multiple applications allowing for streamlined updates to security rules and follow-up on updated security policies. AT-TLS eliminates the need to individually update each program applying the same policy over and over again.
AT-TLS can be enabled for inbound calls, outbound calls, or for both directions. This is important since most of the time, system programmers operate on just part of the communication protocols that apply strictly to their area of responsibility. One should also keep in mind that the remote parts could be running on a different platform without z/OS.
One of the key features of AT-TLS is that it is transparent, this means the application only deals with the plain HTTP or FTP parts of the protocol. The header of the request is updated on the fly and thus it is impossible to determine which protocol in fact is being used. Certain details that would need to be considered for successful communication, for example, in the case of outbound calls, when an application with enabled AT-TLS calls a secured endpoint, the URL must indicate HTTP protocol. It is then updated to the secure version by the AT-TLS and the application remains unaware of this change by default.
Thinking about the above-described behavior where the application is not set to use the secure protocol, a few potential security breaches could come to one’s mind. One of the main questions would be how to avoid using open channels when the configuration of TLS is outside the application. A way to do that is to check the state of the channel that the AT-TLS reports as either disabled, basic, aware, or controlling.
Disabled mode is clear — the application is not using AT-TLS, the feature is either not enabled or some critical configuration is missing. The mode is usually set when the application uses Java TLS libraries.
Basic mode is used when the application implements either the HTTP or FTP protocols without TLS and the AT-TLS makes the bridge between the application and its remote access. This mode is the most straightforward way of using this technology requiring minimum AT-TLS configuration and ensuring that the application uses secured protocols everywhere
Aware mode is probably the most important as it adds on top of the basic mode the possibility to check the state of the communication channel in use. By using native calls to the IOCTL service, an application can query the state of its AT-TLS (e.g.: enabled, disabled, configuration error, etc.). Some basic information about the protocol in use could also be fetched such as the user ID when a caller’s request is signed by a private key. The system would automatically find and map the request with the user that has signed it, thereby making it possible for the application to implement “password-less” authentication.
Controlling mode offers further possibilities for managing during runtime the communication link and the protocols implemented. In this mode, the IOCTL service calls would allow the application to, for example, reset the cipher in use. A detailed description of this can be found in the IBM documentation.
This very high-level overview of AT-TLS and how it can be implemented in a modern mainframe Java application. This can already be used as a starting point to draft designs and software architectures around it, nevertheless, further diving into the technical specifications with sample code snippets is needed to gather the necessary confidence to make use of this ingenious z/OS Communication Server component. Follow-up articles are duly needed and on their way to tell the story of configuring, interacting with the native z/OS libraries, setting up verification, authentication, filter and manage inbound and outbound calls.
Co-authored by Boris Petkov
Further reading: AT-TLS Configuration for the Modern Mainframer
