TLS Explained

16 March 2025

---

Table of contents

TLS (Transport Layer Security)

TLS is a protocol that handles all practical aspects required for establishing a secure communication between two entities. TLS deprecates the older SSL (Secure Socket Layer) protocol . However the term SSL is still used by laymen to refer to TLS

TLS Versions : TLS 1.0, TLS 1.1, TLS 1.2 , TLS 1.3

TLS provides encryption, authentication and integrity (detect tampered messages with message authentication code)

TLS in HTTPS

TLS can be used with many application protocols to provide encryption and authentication using certificates . A common use case is with HTTPS.

HTTPS includes multiple protocols that works in tandem:

• 1) TCP - Data transport
• 2) TLS - Encryption, Digital certificates
• 3) HTTP - Webpage exchange

The process starts with TCP 3 way handshake (SYN, SYNC+ACK, ACK) to establish a TCP connection. This is often quick and happens within 60 to 70ms. Once the TCP connection between client and server is established , then TLS 1.2 protocol kicks in which could take some 140 to 150ms:

• Client → Server : Client Hello
  • Client Hello sends details of cipher suits supported by client
  • Includes a random number called client random
• Server → Client : Server Hello + Server Certificate + Server Key Exchange + Server Hello Done
  • Server sends information for calculating a symmetric key for communication encryption .
  • Special case: Connection will terminate if server cannot find a supported cipher suit in the list sent by client
  • Sever Hello: includes details of cipher suit chosen by server and a random number called Server random
  • Certificate Message: Server sends Server certificate to authenticate for the client to authenticate the server as it is signed by a trusted CA. Full server certificate chain including intermediate and leaf certificates are sent to client. Upon receipt, the client performs verifies the certificate. The steps include
    • 1) Check digital signature of server certificate.
    • 2) Check expiry.
    • 3) certificate chain verification.
    • 4) Domain name check and so on.
  • Server Key Exchange: This optional message is used in some situations where additional data is required such as Diffie Hellman Key Exchange
  • Server Hello Done: Server confirms it finished sending all its messages.
• Client → Server : Client Key Exchange + Change CipherSpecs (CCS)
  • Client Key Exchange: The exchange depends on the key change method decided - for example in RSA client sends calculated premaster secret encrypted by server public key at this point . This helps server to calculate is session key. Upon receipt server decrypts the pre-master secret sent by client and calculate the session key.
  • Change Cipher Spec: This tells server that client is ready to switch to encrypted mode as the client has generated the session key
  • Finished: Indicate that client completed its handshake
• Server → Client : Change CipherSpecs (CCS) + Finish
  • Change CipherSpecs: Server informs the client to switch to encrypted node
  • Finish: This messages is encrypted with symmetric session key server generated

From this point onwards the session key (symmetric key) is used to encrypt all communication between server and client. So the server and client can now move on to use HTTP encrypted with session key (ie HTTPS)

TLS 1.3

Round trip time

TLS 1.2 message exchanges are inefficient at scale. TLS 1.3 protocol brings in several enhancements to TLS 1.2 . One important improvement in TLS 1.3 is the number of roundtrips required for handshake is reduced from two in to one.

1 RTT

TLS 1.3 operates in 1 RTT mode most of the time where the handshake is complete in 1 round trip. This is different from TLS 1.2 which needed 2 round trip.

TLS 1.3 has a simpler cipher negotiation model and a reduced set of key agreement options. As there is limited set of choices, the client can simply choose to send DH key shares in the first message instead of waiting until the server has confirmed which key shares it is willing to support. That way, the server can learn the shared secret and send encrypted data one round trip earlier.

0 RTT

TLS 1.3 supports both 1 RTT and a new Zero Round Trip Resumption (0 RTT) mechanism added in. 0 RTT helps clients to transfer data to servers without having to wait for the handshake to be finished. Overall RTT time is reduced by storing some of the session parameters in server avoiding the need of a round trip when the client connect to server second time onwards. On the negative side it reduces forward secrecy by allowing to decrypt older messages using same session key used in a later sesson. This is not easy to achieve though.

TLS 1.3 : Items removed from TLS 1.2

• RSA key transoprt is removed due to lack of forward secrecy. RSA is computationally very heavy. TLS 1.3 introduces ECDH (ECC/Diffie-Hellman) as a replacement for RSA. This is lighter in computation as compared to RSA.
• RC4 Stream cipher due to redcued security for usage in HTTPS
• AES CBC mode which had vulnerabilities
• SHA-1 for hashing, as we have better algirthm SHA2
• Arbitrary Diffie-Hellman groups
• TLS 1.3 cut short the number of cipher suits supported from a larger number supported in TLS 1.2. Export Ciphers are renoved since they are weak. Export ciphers often use shorter key lengths or less robust algorithms compared to modern ciphers. The smaller list is faster to exchange

Other highlights

• TLS 1.2 messages are tamper protected with Message Authentication Code (MAC). But TLS 1.3 uses digital signatures to secure messages from the beginning.
• TLS 1.3 has less vulnerable session resumption capability.
• TLS 1.3 has only minimal compatibility for previous versions like TLS 1.2.
• All handshake messages after the ServerHello are encrypted in TLS 1.3. This prevents downgrade attack where a man in the middle force the two parties to choose weakest cipher while stronger ciphers are available
• A zero-RTT (0-RTT) mode was added, but at the cost of few security properties
• TLS 1.2 has a new extension called key share extension . Keyshare helps client and the server to establish a key offline and omit the key-share portion of the handshake entirely. In prior versions of TLS, this was a separate message called the Client Key Exchange.

TLS 1.2 is an improvement over TLS 1.1 in 2008.

TLS Record Protocol

TLS uses two sub protocols:

1. Handshake Protocol

Handshake protocol is responsible for authentication, key exchange, and negotiation of security parameters.

RSA Handshake- client generates a symmetric key and then the client encrypts it with the server’s public key and shares across. RSA is getting obsolete since if the private key is leaked out, all older messages can be decrypted.

Diffie-Hellman handshake - Client and Server derives the key without sending it through communication channel. So leaking private key cannot be used to retrieve previous communication and thus maintains forward secrecy.

2. Record Protocol

Record protocol is responsible for encryption application data using symmetric key generated with Handshake protocol. Message Integrity Checks are performed on each record to make sure that data is not tampered.

Record size:

Application data is transmitted in record protocol and the maximum allowed size is 16 KB. Record header may take between 20 to 40 bytes on top of TCP header requirements. Framing overhead reduces as the record size grows. But if the lager record is split into multiple TCP packets, there will be more wait time for packets to arrive contributing to larger latency. It is possible to configure the maximum record size to use

TLS Session Resumption

TLS session has a session identifier which is sent as part of Server Hello message. Using session ID, the client can re-use the session parameters. This helps to reduce the handshake messages next time, by reusing previous session parameters.

Key Exchange algorithms

A key exchange algorithm allows two parties to securely establish a shared secret, even over an untrusted network. This shared secret is later used for symmetric encryption (like AES).

The certificate contains a public key, which is used as part of the key exchange process.The type of public key (RSA, ECDSA, etc.) determines what kind of key exchange is possible

Key exchange algorithm is part of the TLS protocol, not directly a field in the X.509 certificate. The certificate only defines what kind of keys (RSA, EC) are available, which constrains which key exchange algorithms can be used

Choosing key exchange algorithm: During a TLS handshake, the client and server negotiate:

• The cipher suite (which includes the key exchange algorithm)
• Based on what’s supported by both sides
• And what the certificate allows. e.g. If it presents an ECDSA certificate, it will likely use ECDHE for key exchange.

This shows it's an Elliptic Curve key, which would support ECDHE key exchange. But it does not explicitly say "ECDHE" — that's determined at protocol level (TLS), not in the certificate.

Common Key Exchange Algorithms (Used in TLS with Certificates)

• RSA Key Exchange - Client encrypts a pre-master secret using the server’s RSA public key. Certificate Key Type: RSA
• Diffie-Hellman (DH) - Uses DH parameters in the certificate for secure key negotiation. Certificate Key Type: RSA or DH parameters
• Elliptic Curve DH (ECDHE) - A modern, efficient form of DH using elliptic curves.Certificate Key Type:ECDSA or EC keys
• ECDHE + RSA - ECDHE is used for key exchange; certificate is signed with RSA. Certificate Key Type: RSA
• ECDHE + ECDSA - ECDHE used for key exchange; certificate is signed with ECDSA. Certificate Key Type: ECDSA

Cipher Suits

Let us take an example of a cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. Below given is the breakup:

• TLS - Protocol used.
• ECDHE - Key exchange algorithm used for the session - Elliptic Curve Diffie-Hellman Ephemeral
• ECDSA - Authentication algorithm used. Elliptic Curve Digital Signature Algorithm. The server's certificate is signed using ECDSA (instead of RSA)
• WITH_AES_128_GCM - Symmetric encryption: AES with with a 128-bit key in GCM mode
• SHA256 - Hash function used in the TLS PRF (Pseudo Random Function) and for handshake message integrity

DTLS

Datagram Transport Layer Security is often used for VoIP, video streaming, and gaming scenarios where unreliable delivery is acceptable. It is built on top of UDP. TLS cannot be implemented on top of UDP since datagrams may be lost, and reordered. TLS does not allow packets to be decrypted independently, but you can do it for DTLS. A key feature of DTLS is prevention of the denial of service using cookies. This allows to communicate without showing real IP address. During DTLS 1.3 session resumption, a server can send a "cookie" to a client . Client sends this cookie during the resumption attempt. It prevents flooding the server from fake IP address. DTLS handshake is made reliable at protocol level modification measures like retransmission. DTLS packet include data structures for detecting record packet ordering and duplicate packets. This ensures that data arrives in the correct order even if packets are lost or arrive out of sequence.

DTLS is derived from TLS, so many of the security mechanisms and algorithms are the same for DTLS

• DTLS 1.0 is based on TLS 1.1 - First version of DTLS
• DTLS 1.2 is based on TLS 1.2
• DTLS 1.3 is based on TLS 1.3

EAP-TLS

EAP-TLS is an authentication method that uses the TLS protocol within the EAP framework. It is used to securely authenticate users/devices before granting access to a network.

References

• https://crypto.stackexchange.com/questions/93641/can-we-pick-which-key-is-private-or-public-in-asymmetric-encryption-do-the-keys
• https://docs.openssl.org/1.1.1/man1/ciphers/#tls-v12-cipher-suites