Putting Security in the Transport: TLS

At the heart of most security manager’s concerns is transport layer security. The transport is a concern since there is no way to effectively monitor all the devices on a network. Since network sniffers and other devices with promiscuous network interfaces are effectively invisible on the network, it is not possible to be sure “no one is listening”.

What is TLS?

Transport Layer Security or TLS, is intended to address this very problem. TLS provides both data confidentiality (privacy) and data integrity for a network session between two endpoints. To implement these protection features, TLS uses two protocols: the TLS Record Protocol and the TLS Handshake Protocol.

The TLS Record Protocol requires a reliable transport such as TCP and provides symmetric cryptography and integrity. This being said, it is also possible to use the TLS Record Protocol without encryption. Not using the encryption capabilities could be an option where privacy of the data was not a concern, but integrity of the data is.

TLS was designed to provide a secure and extensible protocol, which is capable of interoperating with any application or service. It was also intended to provide additional cryptographic algorithm support, which SSL did not have. The challenge of providing additional cryptographic algorithms was compounded by export controls on cryptographic technologies and requiring backwards compatibility with browsers such as Netscape.

Secure Sockets Layer (SSL), has typically been associated with World Wide Web transactions. It is possible to use TLS in this area; however, this is a highly technical discussion more appropriate for other audiences. Additionally, while TLS has been undergoing development, the Internet community has accepted SSL as a transport for VPN services, as an alternative to the seemingly more complex IPSec implementations.

When designing TLS, the architects had four major goals:

• Provide secure communication between the two parties using cryptographic security features;
• Allow independent programmers to exchange cryptographic parameters within knowledge of the programming language and code used on the remote end;
• Provide a framework capable of supporting existing and new symmetric and asymmetric encryption services as they become available. This in turn eliminates the need for new code or protocols as advances are made; and,
• Improve efficiency at the network by effectively managing the network connections.

Why use TLS?

There are a variety of reasons for wanting to choose TLS over SSL when securing a protocol. SSL has been widely used and associated with HTTP traffic. While SSL and TLS both provide a generic security channel for the desired protocol, when security professionals hear “SSL”, they typically think “HTTP” is the protocol being protected.

Netscape originally developed SSL, while TLS has taken a standards oriented approach managed through the TLS Working Group of the Internet Engineering Task Force (IETF). Consequently, the implementation is not biased toward specific commercial implementations. Finally, there are a number of free and commercial implementations of TLS available.

However, be warned: Developing a secure application using TLS or SSL is not simple and requires extensive technical knowledge of the TLS protocol and the protocol being protected. This knowledge promotes the development of an application capable of handling errors in a secure fashion and limits the attack possibilities against the application.

Protecting data

Protecting data with TLS requires the negotiation of an encryption algorithm. TLS provides support for multiple algorithms including

• DES;
• RC4;
• RC2;
• IDEA;
• Triple DES (3DES); and,
• AES

The reader will notice these are symmetric cryptographic algorithms. Symmetric algorithms are preferred due to the speed of the encryption and decryption process over asymmetric algorithms. The encryption key is unique and generated for each session. The seed or secret for generating the key is negotiated using an alternate protocol, such as the TLS Handshake Protocol.

Ensuring data integrity

Having an encrypted session may not be of much use without ensuring the data was not modified and re-encrypted after the fact. Consequently, the TLS Record Protocol also provides an integrity checking function.

Integrity of the message is ensured using a keyed Message Authentication Code (MAC) using secure a hash function such as SHA and MD5. These are message digest algorithms, which are irreversible making it extremely difficult, if not virtually impossible, to compute a message given the digest. Consequently, use of message digests is an accepted method of verifying the integrity of the message. If a single character in the message is altered, it is virtually impossible to generate the same message digest.

The TLS Protocols

As mentioned previously, there are two protocols in the TLS suite. Aside from the confidentiality and integrity functions of the TLS Record Protocol, the Record Protocol also encapsulates other higher-level protocols. Of the protocols supported, the TLS Handshake Protocol is often used to provide the authentication and cryptographic negotiation.

The TLS Handshake Protocol provides two essential elements to establishing the session. These are: Authenticating at least one of the endpoints using asymmetric cryptography; The negotiation of a shared secret.

The shared secret is used to generate the key for the symmetric cryptography used in the Record protocol. However, of importance here is the high level of protection placed upon the secret. During the negotiation, because the secret is protected by asymmetric cryptography, it is not possible for an eavesdropping attacker to recover the secret. Secondly, the manner in which the negotiation occurs means any attempt by an attacker to modify the communication will be detected. These features provide a high level of security and assurance upon the privacy and data integrity of the connection.

Additionally, The Handshake Protocol also provides other sub protocols to assist in operation of the protected session. The entire protocol stack is presented in Figure 1.

Figure 1 — TLS Protocol Stack

Understanding the TLS Handshake Protocol

The TLS Handshake Protocol allows two peers to agree upon security parameters for the TLS Record layer, authenticate, initiate those negotiated security parameters and report errors to each other.

During the session negotiation phase, the Handshake Protocol on each peer negotiates the security parameters in Table 1.

Table 1 — Security Parameters

* Session identifier — This value is chosen by the server and is an arbitrary value to identify an active or resumable session state.

• Peer certificate — This is the X.509v3 [X509] certificate of the peer.
• Compression method — The algorithm used to compress data prior to encryption.
• Cipher spec — This identifies the bulk encryption algorithm, the MAC algorithm and any other specific cryptographic attributes for both.
• Master secret — This is a 48-byte secret shared between the client and server.
• Is resumable — A flag indicating whether the session can be used to initiate new connections.

Once the session is initiated however, the application can request a change in the cryptographic elements of the connection. The change is handled through the “change cipher spec protocol”, which sends a message to the peer requesting a change to the cipher properties. The change itself is encrypted with the current cipher values to ensure the request and associated information cannot be deciphered if intercepted.

How the Protocol Works

For TLS to properly protect a session using cryptographic features, it must negotiate the cryptographic parameters. Figure 2 illustrates establishing the session.

Figure 2 — Handshake Setup

Upon initiating a TLS connection, the two nodes must establish a “handshake” and negotiate the session parameters. These parameters include the cryptographic values, optional authentication and generated shared secrets.

The process breaks down as follows:

1. Each node exchanges a “hello” message to communicate supported cryptographic algorithms, select one which is mutually acceptable, exchange random values used for session initialization and finally to check to see if this is the resumption of a previous session;

2. Both nodes then exchange the needed cryptographic parameters to agree on a “pre-master” secret;

3. Both nodes exchange their certifications and appropriate cryptographic information to authenticate;

4. Both nodes use the pre-master secret from step 2 to generate a master value, which is then exchanged;

5. Each node provides the agreed security parameters to the TLS record layer; and,

6. Verifies the other has calculated the same security parameters and the session was not tampered with by an attacker.

While TLS has been designed to minimize the opportunity an attacker has to defeat the system, it may be possible according to RFC 2246 for an attacker to potentially get the two nodes to negotiate the lowest level of agreed encryption. Some methods are described later in the article.

Regardless, the higher-level protocols should never assume the strongest protocol has been negotiated and should ensure whatever requirements for the specific connection have been met. For example, 40 bit encryption should never be used, unless the value of the information is sufficiently low as to be worth the effort.

Dissecting the Handshake Protocol

When the client contacts the server to establish a connection, the client sends a client hello message to the server. The server must respond with a server hello message or the connection fails. This is extremely important as the hello messages provide the security capabilities of the two nodes.

Specifically, the hello message provides the following security capabilities to the other node:

• TLS protocol version;
• Session ID;
• Available cipher suite; and,
• Compression method.

As mentioned above, both nodes compute a random value that is also exchanged in the hello message.

Exchanging the keys can involve up to four discreet messages. The server first sends its certificate, provided the server is to be authenticated. If the certificate is only for signing the server then sends it’s public key to the client. The server then sends a “server done” message, indicating it is waiting for information from the client.

The server may send a request to the client for authentication, whereby the client sends its certificate followed by the client’s public key and the “client done” message. The client done message is sent using the agreed to algorithm, keys and secrets. The server then responds with similar information and the change to the new agreed cipher is complete.

This exchange is illustrated in Figure 3.

Figure 3 — Handshake Exchange

At this point, the handshake between the two devices is complete and the session is ready to send application data in the encrypted session.

Resuming an Existing Session

When the client and server agree to either duplicate an existing session to continue a previous session, the handshake is marginally different. In this case, the client sends the “hello” message using the Session ID to be resumed. If the server has a match for that session ID and is willing to re-establish the session, it responds with a “hello” message using the same Session ID. Both client and server then switch to the previously negotiated and agreed to session parameters and transmit “done” messages to the other.

If the server does not have a match for the Session ID, or is not willing to establish a session based upon the previous parameters, a full handshake must take place.

Certificates The TLS protocol is meant to be extensible and provide support in a wide variety of circumstances. Consequently, the following certificate types are supported:

Table 2 — Supported Certificate Types

• RSA. — This is the RSA public key, which must support use of the key for encryption.
• RSA_EXPORT. — This is an RSA public key with a length greater than 512 bits used only for signing. Alternatively, it is a key of 512 bits or less which is valid for either encryption or signing.
• DHE_DSS — DSS public key.
• DHE_DSS_EXPORT — DSS public key.
• DHE_RSA — This is an RSA public key used for signing.
• DHE_RSA_EXPORT. — This is an RSA public key used for signing.
• DH_DSS — This is a Diffie-Hellman key. The algorithm used to sign the certificate should be DSS.
• DH_RSA — This is a Diffie-Hellman key. The algorithm used to sign the certificate should be RSA.

NOTE: Due to current restrictions documented in the United States export laws, RSA values larger than 512 bits for key exchanges may not be exported from the United States.

Inside the TLS Record Protocol

The Record Protocol is responsible for accepting cleartext messages, fragmenting them into chunks, compressing the data, applying a Message Authentication Code, encryption and transmission of the result. Likewise, when an encrypted message is received, the protocol decrypts the data, verifies it using the MAC, decompresses and reassembles the data, which is in turn delivered to the higher level clients. This process is illustrated in Figure 4.

Figure 4 — TLS data processing

Achieving this process uses four record protocol clients: — The Handshake protocol; — The alert protocol; — The Change Cipher Spec protocol; and,. — The Application Data protocol.

The specific functions used to provide the Record protocol services are controlled in the TLS connection state. The connection state specifies the — Compression algorithm; — Encryption algorithm; and, — MAC algorithm.

Additionally, the appropriate parameters controlling the behaviors of the selected protocols are also known, specifically the MAC keys, bulk encryption keys and initialization vectors for both the read and write directions.

While the record protocol performs the specific functions noted here, the TLS Handshake Protocol performs the negotiation of the specific parameters.

The parameters used in the TLS Record protocol to protect the session are defined in Table 3. These values are used for both sending and receiving data during the TLS session.

Table 3 — TLS Record Protocol Parameters

• Connection end — The value of this parameter determines if this is the sending or receiving end of the connection.
• Bulk encryption algorithm — This is the negotiated algorithm for bulk encryption, including the key size, how much of the key is secret, block or stream cipher, cipher block size if appropriate and whether this is an export cipher.
• MAC algorithm — This is the Message Authentication Code algorithm and includes the size of the hash returned by the MAC algorithm.
• Compression algorithm — This is the negotiated compression algorithm and includes all information required for compressing and decompressing the data.
• Master secret — This is a 48 byte secret shared between the two peers.
• Client random — This a 32 byte random value provided by the client.
• Server random — This is a 32 byte random value provided by the server.

After the Handshake Protocol negotiates the security parameters, they are passed to the Record Protocol function to generate the appropriate keys. Once the keys are generated, the TLS protocol tracks the state of the connection, ensuring proper operation and minimizing the risk of tampering during the session.

Handling Errors

The TLS protocol carries data between a client and a server using an encrypted channel. This provides data confidentiality. Likewise, the protocol also ensures data integrity using a one-way hash, or Message Authentication Code for each message. However, things sometimes go wrong and when they do, the protocol must be able to inform the user and take the appropriate action.

TLS Alert messages carry the severity of the message and a description of the alert. If the alert severity is fatal, the connection is terminated immediately. For other severity levels, the session may continue but the session ID is invalidated, which in turn prevents the failed session from being used to establish new sessions later.

The TLS protocol provides Closure and Error alert types. Closure alerts are not errors, but a method for one side of the communication exchange to indicate the connection is being terminated. Error alerts indicate an error has occurred and what the error is.

When errors occur, the side detecting the error transmits an error message to the other side. If the error is fatal, then both sides immediately terminate the connection and invalidate all keys, session identifiers and secrets. This prevents the re-use of information from the failed connection.

Fata error messages always result in the termination of the connection. However, when a non-fatal or warning message is received, continuing the connection is at the discretion of the receiving end. If the receiver decides to terminate the connection, a message to close the connection is transmitted and the connection is terminated.

Attacking TLS

The goal of TLS is to provide a secure channel for a higher-level protocol as seen in Figure 5.

Figure 5 — Encapsulating Higher Level Protocols

Because the higher-level protocol is encapsulated within a secured transport, the vulnerabilities associated with the higher-level protocol are not of particular importance. There are however, documented attacks and attack methods which could be used against TLS.

One such attack is the man in the middle, where the middle attacker attempts to have both the TLS client and server drop to the least secure method supported by both. This is also known as a downgrade attack.

Figure 6 — The Man in the Middle

Figure 6 illustrates a man in the middle attack. In this scenario, the attacker presents itself to the client as the TLS server, and to the real TLS server as the client. In this manner, the attacker can decrypt the data sent by both ends and store the data for later analysis.

An additional form of downgrade attack is to cause the client and server to switch to an insecure connection, such as an unauthenticated connection. The TLS protocol should prevent this from happening, but the higher-level protocol should be aware of its security requirements and never transmit information over a connection that is less secure than desired.

A second attack is the timing cryptanalysis attack. This attack is not known to have been attempted against production systems and may not even be practical. With timing cryptanalysis, specific attention to the time taken for various cryptographic functions is required and used as the basis of the attack. Given enough samples and time, it may be possible to recover the entire key. This attack is not specific to TLS, but to public key cryptosystems in general. Paul Kocher discovered the timing cryptanalysis attack in 1996 and the exact method of the attack is left for the reader to review.

A third attack is the million-message attack discovered by Daniel Bleichenbacher to attack RSA data using PKCS#1. Here, the attacker sends chosen ciphertext messages to the server in an attempt to discover the pre_master_secret used in the protocol negotiation for a given session. Like the timing cryptanalysis attack, there is no evidence this attack has been used against production systems. Daniel Bleichenbacher discovered and documented this attack in 1998.

TLS Implementations

Several implementations of TLS commonly incorporate SSL as well. The available distributions include both commercial and open source implementations in the C, C++ and Java programming languages.

Open Source OpenSSL — http://www.openssl.org/ GNU TLS Library — http://www.gnu.org/software/gnutls/ PureTLS — http://www.rtfm.com/puretls

Commercial SPYRUS — http://www.spyrus.com/content/products/SSLDeveloperToolkits_N7.asp Certicom — http://www.certicom.com Netscape Communications — http://www.netscape.com RSA — http://www.rsasecurity.com Baltimore — http://www.baltimore.com Phaos Technology — http://www.phaos.com Sun — http://www.javasoft.com

Summary

This article has presented what TLS is, how it works and the common attack methods. While SSL continues to maintain momentum and popularity, support for TLS as the secured transport method is increasing dramatically. Like SSL, TLS provides a secured communications channel for a higher layer protocol, with TLS providing protocol independent implementations. SSL is typically associated with HTTP traffic, while TLS can support protocols aside from HTTP.

Web articles on implementing SMTP, FTP and HTTP over TLS are available, just to name a few higher-level protocols. TLS implementations provide support for SSL clients as well, making the implementation backwards compatible and standards based.

Finally, like SSL, TLS is prone to some attack methods, however, vigilance, attention to secure programming techniques and configuration practices should alleviate most current attacks against this protocol suite.

References

Dierks, T, and C Allen. “RFC 2246 The TLS Protocol.” IETF Network Working Group January 1999.

Blake-Wilson, S, D Hopwood, and J Mikkelsen. “RFC 3546 TLS Extensions.” IETF Network Working Group June 2003.

Rescola, Eric. SSL and TLS. New York: Addison-Wesley. 2001.

Kocker, Paul. Timing attacks on Implementations of Diffe-Hellman, RSA, DSS and Other Systems. 1996.

Copyright 2018, Chris Hare