Transport Layer Security (TLS)

Secure Sockets Layer (SSL) is a protocol standard developed by the Netscape Communications Corporation that uses encryption to provide confidentiality and authentication between two TCP/IP applications. As SSL gained in popularity, the IETF formally standardized SSL, made a few improvements and changed the name to Transport Layer Security (TLS). TLS is defined in Request for Comments (RFC) 2246.

For simplicity, the acronym TLS is used to denote TLS and SSL in this section.

A TLS connection begins with a handshake. As the name suggests, the handshake entails the initial setup of a TLS connection. During the TLS handshake, an exchange of information occurs that includes the following (this has been simplified):

Authentication of the server
A decision about how the data is to be encrypted
Optionally, the authentication of the client

On z/OS, the FTP server, the FTP client, and the TN3270 server all support TLS. Configuration of TLS is similar in all three environments, and the principles involved are common throughout as well. RFC 2246 describes TLS in general–but FTP has the added complexity of a control and data connection.

To clarify how FTP handles TLS, RFC 4217 has been published. An easy way to introduce the principles is by beginning with statements in the FTP.DATA file required to support a TLS connection; see Figure 1.

Figure 1. FTP.DATA configuration statements

 CIPHERSUITE SSL_DES_SHA            ;for testing, keep these cipher
 CIPHERSUITE SSL_RC2_MD5_EX         ;cipher statements
 CIPHERSUITE SSL_RC4_MD5_EX         ;in this order
 CIPHERSUITE SSL_3DES_SHA           ;export restricted?
 SECURE_FTP REQUIRED
 SECURE_LOGIN NO_CLIENT_AUTH
 SECURE_CTRLCONN PRIVATE
 SECURE_DATACONN PRIVATE
 KEYRING FTPring

By examining the statements in Figure 1, the principles of setting up TLS become more apparent.

CIPHERSUITE

This specifies the encryption and authentication algorithms that this z/OS FTP server supports. The actual algorithms used are negotiated during the TLS handshake. In this sample, the FTP server will support any of the four combinations listed.

Tip: In almost all of the z/OS TCP/IP configuration files, a semicolon (;) placed anywhere on a line indicates the beginning of a comment.

SECURE_FTP

Any FTP client connecting to this FTP server is required to use TLS. Non-TLS connections are rejected. If desired, an FTP server can be configured to have TLS as an option. The choice then becomes the client's. Flexibility is not necessarily negative in this case--but it does mean that end users with FTP clients may accidentally connect without using TLS.

SECURE_LOGIN

This FTP server is configured not to authenticate any FTP clients.

Note: TLS authenticates by using a certificate. By default, TLS requires that a server always send a certificate to the client. This certificate allows the client to verify that it is really talking to the server it attempted to contact. The idea here is to prevent a computer in the middle from pretending it is the server.

SECURE_CTRLCONN

SECURE_DATACONN

These two statements control whether or not the server will require the FTP control connection and the FTP data connection to be secure. If an FTP server is being configured for security purposes, it makes sense to make sure that encryption occurs on all communications between the client and the server. Using PRIVATE as the operand means that the FTP server will require TLS for both control and data connections. A surprising aspect of TLS is that the data connection can be set with an operand of CLEAR, which will allow data to be sent unencrypted.

KEYRING

The key ring is the location of the certification repository. The default certificate in this key ring is the certificate that will be sent out by the FTP server to any clients.

These parameters in the FTP.DATA configuration file control the behavior of the FTP server application. Because the TLS interface is be implemented at the top of the transport layer (as shown in Figure 2), the FTP server requires specific configuration changes in order to function with TLS. From an application programming perspective, the source code of the FTP server must be modified (by the original developer of the application) to operate using TLS.

Figure 2. TLS in the IP layer model

If the FTP server requires modifications to support TLS, what about the FTP client? The FTP client also requires similar configuration changes. Of special note, however is the certificate requirements.

As noted, the FTP server sends out a certificate to prove its identity. How does the FTP client validate this certificate? In the FTP client key ring, there must be a certificate that can vouch for the authenticity of the certificate received from the FTP server. Normally, a Certificate Authority (CA) certificate is used for this purpose.

Note: The key ring used by the FTP application is under the control of an external security manager such as RACF. The term ring is perhaps a confusing one: it simply refers to a subset of a database. Using RACF commands, a ring is populated with certificates.