Transport Encryption: Understanding Transport Layer Security

To protect data-in-motion, most will implement transport encryption mechanisms and cryptographic protocols designed to provide communications security over a computer network. The Transport Layer Security protocol, TLS for short, is an example of such a protocol.

Background

Transport Layer Security (TLS) is a cryptographic protocol used to establish a secure communications channel between two systems. It is used to authenticate one or both systems; and protect the confidentiality and integrity of information that passes between systems. Standardized by the Internet Engineering Taskforce (IETF), TLS has undergone several revisions to improve security to block known attacks and add support for new cryptographic algorithms.

TLS is still widely known by the name of its predecessor Secure Socket Layer (SSL). SSL was originally developed by Netscape and released SSL 2.0 in 1995 and SSL 3.0 in 1996. TLS was first introduced in 1999 as a new version of SSL which was based on SSL 3.0. SSL 3.0 was superseded by TLS 1.0 in 1999, TLS 1.1 in 2006, TLS 1.2 in 2008, and TLS 1.3 in 2018. Over the years, new versions of the protocols have been released to address vulnerabilities and support stronger, more secure cipher suites and algorithms.

As new protocols are introduced, old protocols reach their end of life and for security reasons must no longer be utilised.

The goals of the TLS protocol, in order of priority, are as follows: (as per RFC 5246: TLS1.2)

1. Cryptographic security: TLS should be used to establish a secure connection between two parties.
2. Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
3. Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
4. Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.

One of the advantages of TLS is, is that it is very easy to deploy, but one caveat is; is that it usually is rather hard to do correctly. It might end up giving a false sense of security in which people will put trust; often where it didn’t deserve it.

To ensure that TLS provides the necessary level of security, correct configuration and understanding; is key for administrators and developers, to secure their servers and applications. Ideally one will provide services or abstract the need to others (while still applying defence in depth), who do have such competence and understanding or responsibility.

The TLS protocol enables two parties to identify and authenticate each other and communicate with confidentiality and data integrity. The protocol itself has two layers: A Record Protocol and a Handshake Protocol. These are layered above a transport protocol such as TCP/IP. TLS uses both asymmetric and symmetric cryptography techniques on different stages of a connection and data-transmission.

An TLS connection is initiated by an application which becomes the TLS client. The application which receives the connection becomes the TLS server. Every new session begins with a handshake, as defined by the TLS protocol.

During both client and server authentication there is a step that requires data to be encrypted with one of the keys in an asymmetric key pair and decrypted with the other key of the pair. A message digest is used to provide integrity.

Diagrams

The establishment of trust & secure transmission

Authentication

The identity of the communicating parties can be authenticated using public-key (asymmetric) cryptography. This authentication can be made optional but is generally required for at least one of the parties (typically the server).

The exchange of so-called digital certificates or identity certificates during the TLS handshake is part of the authentication process. A certificate is a proof of identity and ownership; of a public key given by Certificate Authorities (CAs). The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate's contents (called the issuer, usually a CA). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject.

For server authentication, the client uses the server's public key to encrypt the data that is used to compute the secret key. The server can generate the secret key only if it can decrypt that data with the correct private key.

For client authentication, the server uses the public key in the client certificate to decrypt the data the client sends during the handshake. The exchange of messages that are encrypted with the secret key confirms that authentication is complete.

If any of the trust and/or authentication steps fail, the handshake fails, and the session should terminate.

Certificate validation

The TLS client must verify the server's certificate, and the TLS server verifies the client's certificate (if provided). There are four aspects to this verification:

1. The digital signature is checked.
2. The certificate chain is checked.
3. The expiry and activation dates and the validity period are checked.
4. The revocation status of the certificate is checked.

Encryption and the use of secret keys

During a TLS handshake; a secret key is generated to encrypt data between the TLS client and server. The secret key is used in a mathematical formula that is applied to the data to transform plaintext into unreadable ciphertext, and ciphertext into plaintext.

The secret key is generated from the random text sent as part of the handshake and is used to encrypt plaintext into ciphertext. The secret key is also used in the MAC (Message Authentication Code) algorithm, a message digest, which is used to determine whether a message has been altered.

If the secret key is discovered, the plaintext of a message could be deciphered from the ciphertext, or the message digest could be calculated, allowing messages to be altered without detection. Even for a complex algorithm, the plaintext can eventually be discovered by applying every possible mathematical transformation to the ciphertext. To minimize the amount of data that can be deciphered or altered if the secret key is broken, the secret key can be renegotiated periodically. When the secret key has been renegotiated, the previous secret key can no longer be used to decrypt data encrypted with the new secret key.

Information Security – CIA Triad

Confidentiality

TLS uses a combination of symmetric and asymmetric encryption to ensure message privacy. During the TLS handshake, the TLS client and server agree on an encryption algorithm and a shared secret key to be used for one session only. All messages transmitted between the TLS client and server are encrypted using that algorithm and key, ensuring that the message remains private even if it is intercepted. TLS supports a wide range of cryptographic algorithms.

A public-key system has the property of forward secrecy if it generates one random shared secret key per session to complete a key agreement, without using a deterministic algorithm. This means that the compromise of one session cannot compromise others as well, and there is no one secret value whose acquisition would compromise multiple sessions.

Integrity

TLS provides data integrity by calculating a message digest. Use of TLS ensures for data integrity during transmission, provided that the Cipher Suite used includes a message authentication code algorithm.

It is important to understand that message authentication does not include the property of non-repudiation, as the source sending the data might have been compromised. It only allows you to verify the authenticity of the message sent, not the actual contents sent by the message. (it only secures the channel, not the data)

One should always avoid choosing a Cipher Suite whose MAC algorithm is listed as "None". Use of deprecated algorithms like MD5 or 3DES is also discouraged as its strength is considered to be weak.

Availability

TLS does not provide any availability as such by itself. It can help improve availability in some scenarios, such as when used with client certificate, a TLS proxy or load-balancer can be configured to reject unauthenticated or improperly authenticated connections before proxying it to the intended application server.