How Does TLS Work? | From Handshake To Encrypted Data

TLS protects a connection by authenticating the server, deriving shared secrets, then encrypting data and detecting in-transit changes.

A browser does not send an encryption password to a server. Seeing how TLS works starts with one fact: both sides derive matching session secrets, the server proves control of the signing material tied to its certificate, and application data is then protected with symmetric authenticated encryption.

TLS follows a simple sequence: agreement first, authentication next, protected records after that. HTTPS uses TLS under HTTP, but TLS itself is application-independent and can protect many protocols that run over a reliable, ordered transport.

TLS Creates Three Security Properties

TLS is built to provide authentication, confidentiality, and integrity between two endpoints. The server is authenticated in a normal certificate-based connection, while client authentication is optional.

• Authentication: the client checks that it reached the intended server rather than an impostor presenting an unrelated certificate.
• Confidentiality: application data is encrypted so a network observer cannot read the protected payload.
• Integrity: protected records carry authentication data that lets the receiver detect modification in transit.

TLS does not make the application itself trustworthy. A phishing site can still have a valid certificate for its own domain, and malware running on an endpoint can read data before encryption or after decryption.

What Happens During A TLS 1.3 Handshake?

A full TLS 1.3 handshake lets the client and server agree on cryptographic parameters, derive shared secrets, authenticate the server, and confirm that the handshake was not altered. A normal full handshake lets the client send protected application data after one network round trip.

1. ClientHello: the client offers supported TLS versions, cipher suites, signature algorithms, extensions, and usually an ephemeral Diffie-Hellman share.
2. ServerHello: the server selects compatible parameters and returns its own Diffie-Hellman share. Both sides can now calculate the same shared secret without transmitting that secret across the network.
3. EncryptedExtensions: the server sends negotiated extension data. In TLS 1.3, handshake messages after ServerHello are encrypted.
4. Certificate: in certificate-based authentication, the server sends its certificate chain so the client can validate the server identity.
5. CertificateVerify: the server signs the handshake transcript with its private signing material, proving possession of the secret component associated with the certificate.
6. Finished: the server sends a MAC over the handshake transcript. The client verifies it, then sends its own Finished message.

The Finished checks bind the negotiated parameters, authentication, and derived secrets together. A changed handshake transcript causes verification to fail rather than silently producing a different protected session.

Certificates Authenticate The Server, Not The Traffic

A TLS certificate helps a client decide whether the server identity is acceptable; the certificate is not the secret used to encrypt every byte of the connection. The client checks the certificate chain, the expected server name, and the signatures needed to establish trust under the application’s certificate-validation rules.

TLS 1.3 then uses CertificateVerify to prove that the server possesses the private signing material corresponding to the certificate. The bulk traffic is protected with symmetric session secrets derived from the handshake, which is much more efficient than applying asymmetric cryptography to every application record.

TLS 1.3 Now Lives In RFC 9846

TLS 1.3 is currently specified by RFC 9846, published by the IETF in July 2026. RFC 9846 replaces RFC 8446 while keeping the protocol version at TLS 1.3 and remaining backward compatible with implementations of the earlier specification.

The current TLS 1.3 protocol specification also forbids negotiating TLS 1.0 and TLS 1.1. TLS 1.2 can still be negotiated when both peers support and accept it, but TLS 1.3 is the newer protocol definition.

How TLS Works After The Handshake

TLS switches from negotiation to record protection once the required Finished messages are sent and validated. The record layer breaks application traffic into records and protects each record with authenticated encryption.

TLS 1.3 uses AEAD ciphers, which combine encryption and authentication in one operation. Separate traffic secrets are derived for each direction, so client-to-server traffic and server-to-client traffic do not reuse one identical encryption state.

Ephemeral Diffie-Hellman exchanges in TLS 1.3 also provide forward secrecy. If a server’s long-term signing secret is exposed later, previously captured sessions are not automatically decrypted because their traffic secrets came from ephemeral handshake material rather than the certificate’s long-term signing secret alone.

Session Resumption And 0-RTT Trade Speed For Constraints

TLS 1.3 can resume a previous relationship using resumption secret material derived from an earlier connection, reducing repeated authentication work. Some resumed connections can also use 0-RTT early data, letting the client send application data in its first flight.

0-RTT has weaker security properties than ordinary 1-RTT TLS 1.3 data. The current specification says early data has no protocol-level guarantee of forward secrecy and no guarantee against replay between connections, so applications should restrict 0-RTT to operations that remain acceptable if repeated.

Does TLS Hide Everything About A Connection?

TLS protects application content in transit, but it does not make the connection invisible. Network observers can still see information such as endpoint IP addresses, connection timing, and the amount of traffic being exchanged.

TLS also does not certify that a website is honest, error-free, or free of malicious code. TLS authenticates the connection according to the configured identity rules and protects data while it crosses the network.

From Connection Start To Protected Bytes

A TLS 1.3 connection can be reduced to a short sequence that explains the whole mechanism without hiding the cryptography behind the padlock icon. The sequence shows where negotiation ends and protected application traffic begins.

1. The client offers protocol choices and fresh Diffie-Hellman material.
2. The server selects compatible parameters and returns its own fresh material.
3. Both sides independently calculate matching shared secrets.
4. The server sends encrypted parameters plus certificate-based authentication when certificates are in use.
5. The client verifies the certificate, CertificateVerify signature, and Finished data.
6. Both endpoints derive directional traffic secrets from the handshake secrets.
7. The record layer uses authenticated encryption to protect application data in both directions.

The important distinction is that TLS does not send the session secret across the network and does not use the website certificate as the bulk-data encryption secret. The handshake establishes trust and shared secrets; the record layer turns those secrets into protected application traffic.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback