Transport Layer Security (TLS)

TLS is a widely adopted security protocol designed to facilitate privacy and data security for communications over the internet, it is implemented by HTTPS. A primary use case of TLS is encrypting the communication between web applications and servers. TLS has several properties:

• Encryption: hides the data being transferred from third parties.
• Authentication: ensures that the parties exchanging information are who they claimed to be.
• Integrity: verifies that the data has not been forged or tampered with.

Difference between TLS and SSL

TLS is the successor of Secure Sockets Layer (SSL) and has become the industry standard. It addressed various security vulnerabilities of the SSL by introducing stronger cryptography algorithms (e.g. AES) and message authentication (e.g. HMAC). TLS was designed to maintain backward compatibility with SSL, allowing systems supporting TLS to communicate with systems supporting SSL.

TLS handshake

TLS works by establishing a secure communication channel between the client (typically a web browser) and the server. The TLS handshake protocol is the initial step where the client and server authenticate each other, negotiate encryption algorithms, and establish session keys, this step makes further communication possible. TLS handshake employs two kind of key exchange algorithms, RSA and Diffie-Hellman.

TLS handshake using RSA

Below is the TLS handshake process using Asymmetric Cryptography.

1. The “client hello” message The client initiate the handshake by sending a “hello” message to the server. The message will include which TLS version the client supports, the encryption algorithms supported, and a string of random bytes known as the “client random”.
2. The “server hello” message In reply to the client hello message, the server sends a message containing the TLS version selected by the server, server’s TLS certificate along with its public key, the server’s chosen encryption algorithm, and the “server random”, another random string of bytes that’s generated by the server.
3. Authentication The client verifies the verser’s TLS certificate with the CA that issued it. This confirms that the server is who it says it is.
4. Premaster secret The client sends one or more random string of bytes, the “premaster secret”. The premaster secret is encrypted with the public key of the server’s and can only be decrypted with the private key by the server.
5. Session key generation Both client and the server use the exchanged client random, server random, and the premaster secret to independently generate the session keys used for encryption and decryption.
6. Client is ready The client sends a “finished” message that is encrypted with a session key.
7. Server is ready The server sends a “finished” message that is encrypted with a session key.
8. Secure symmetric encryption is achieved The handshake is completed, and further communication can start using the session keys for symmetric encryption.

TLS handshake using DH

Below is the TLS handshake using Diffie-Hellman Key Exchange algorithm.

1. The “client hello” message Similar to RSA method, the client sends a client hello message with the TLS version, encryption algorithm, and client random.
2. The “server hello” message The server replies with its TLS certificate, server selected encryption algorithm, the server random, and the server’s digital signature.
3. Digital signature confirmed The client verifies the server’s digital signature, confirming that the server is who it says it is.
4. Client DH parameter The client sends its DH parameter to the server.
5. Premaster secret Instead of client generating the premaster secret and sending it to the server, as in an RSA handshake, the client and server use the DH parameters they exchange to calculate a matching premaster secret separately.
6. Session key generation Client and server calculate session keys from the premaster secret, client random, and server random, just like in an RSA handshake.
7. Client is ready
8. Server is ready
9. Secure symmetric encryption is achieved

After the handshake is completed, the client and the server can securely exchange data using symmetric encryption. The symmetric encryption key is derived form the session keys established during the handshake. Once a session is ended, the two parties have to reestablish the handshake to reopen the connection.

TLS certificate

TLS certificate type of Digital Certificate, which is a data file that contains domain name, the organisation that owns the certificate, the Certificate Authority (CA) that issues the certificate, the server public key, and other details. Once the certificate is issued, it needs to be installed and activated on the website server, web service providers can usually handle this for the website. After this, the website will be able to load over HTTPS protocol.

Heartbeat extension

Heartbeat extension is a feature of the TLS protocol, it is designed to maintain a secure connection’s state by allowing the transmission of heartbeat requests and responses between a client and server. Negotiating all the parameters in handshake is costly, this mechanism helps keep the connection alive without the need to renegotiate the connection each time. The heartbeat extension allows the client and server to exchange periodic “heartbeat” messages to ensure that the receiver is still alive and the connection remains open. This is particularly useful for long-lived connections that might otherwise be closed due to inactivity.

How the heartbeat extension works

• Heartbeat request
  • Either the client or the server can send a heartbeat request to the other party. The request includes a payload and a padding field.
• Heartbeat response
  • Upon receiving the heartbeat request, the recipient send a heartbeat response. The response echoes back the payload and padding from the request. If the response has matching payload and padding, it suggests that the connection is still active and the server is responsive.

Vulnerability in heartbeat extension

The heartbeat extension had a discovered vulnerability in 2014, the vulnerability arose from improper bounds checking on the heartbeat request’s payload length. The attacker could craft a heartbeat request with a claimed payload length larger than the actual payload, causing the server to return additional memory contents from its memory space. Exploiting this vulnerability, the attacker could access sensitive information stored in the server’s memory. This vulnerability was later patched by ensuring proper bounds checking on the payload length.

Limitations of TLS

• Non-trivial cost of public key cryptography
  • The public key cryptography used during TLS handshake is computationally intensive, such as RSA, DSA key exchange require significant CPU resources.
  • On mobile and IoT devices, the energy consumption for such cryptographic operation can be significant, reducing battery life.
• Buying/maintaining certificates
  • Obtaining SSL/TLS certificates from CAs involves financial costs, which can be a burden for small organisations or individuals.
  • Certificates have expiration dates and must be renewed periodically.
• Latency
  • The TLS handshake involves multiple round trips between the client and server before the secure connection is established. This increases the latency.
• TCP level DoS
  • TLS does not inherently protect against DoS attacks at the TCP level, when an attacker can exhaust server resources by initiating numerous TLS handshakes.
• Issues TLS do not take care of
  • TLS only secure the communication channel, it does not protect against application level attacks, such as SQL injection, client/server side vulnerabilities.

---

Back to parent page: Network Security and Cryptography

Cyber_SecurityNetwork_securityHTTPSTLSINFO2222

Reference - https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ - https://www.baeldung.com/cs/replay-attacks - https://venafi.com/blog/where-tlsssl-handshake-most-vulnerable/