TLS Encryption: How Transport Layer Security Protects Data in Transit

Every time a browser loads a webpage or an email client syncs messages, the connection is protected by TLS encryption. Without it, data travels in plaintext and is readable by anyone positioned between sender and receiver.

TLS encryption protects against eavesdropping, credential interception, and data tampering across the internet. For IT teams managing enterprise networks, TLS is also the foundation of EAP-TLS, the strongest wireless authentication protocol available under IEEE 802.1X.

This guide covers how TLS encryption works, walks through the handshake process, compares TLS versions and cipher suites, and explains how organizations use TLS-based authentication to secure network access.

What Is TLS Encryption?

Transport Layer Security (TLS) is a cryptographic protocol that establishes an encrypted channel between two endpoints, typically a client (browser, application, or device) and a server. TLS sits between the transport layer (TCP) and the application layer in the network stack, encrypting data before it leaves the sender and decrypting it on arrival.

TLS performs three functions:

• Encryption: Converts plaintext into ciphertext so third parties cannot read intercepted data.
• Authentication: Verifies the identity of the server (and optionally the client) using digital certificates issued by a Certificate Authority (CA).
• Data integrity: Uses message authentication codes (MACs) to detect any modification or tampering during transit.

HTTPS, the secure version of HTTP, is the most visible implementation of TLS. When a browser shows a padlock icon, it means that TLS encryption is active. But TLS extends well beyond web browsing. Email (SMTP over TLS), file transfers (FTPS), VoIP, DNS over TLS, and enterprise Wi-Fi authentication (EAP-TLS) all rely on the same underlying protocol.

How Does TLS Encryption Work?

TLS encryption combines two types of cryptography. Asymmetric encryption (public/private key pairs) handles identity verification and key exchange during setup. Symmetric encryption (shared session keys) handles bulk data transfer after the connection is established.

This two-phase approach balances security with performance. Asymmetric encryption is mathematically strong but computationally expensive. Symmetric encryption is fast but requires both parties to share a secret key. TLS uses the first to securely deliver the second.

The TLS Handshake Process

The TLS handshake is the sequence that negotiates encryption parameters, authenticates the server, and generates session keys. It happens before any application data is exchanged.

Here are the key steps in the handshake process in TLS 1:

1. Client Hello: The client sends its supported TLS versions, cipher suites, and a random value to the server.
2. Server Hello: The server selects a TLS version and cipher suite from the client’s list and responds with its own random value.
3. Certificate: The server sends its TLS certificate, which contains the server’s public key and is signed by a trusted CA.
4. Certificate verification: The client checks the certificate chain against its trusted root CA store, confirms the certificate has not expired or been revoked, and validates that the domain matches.
5. Key exchange: The client generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server. Both sides derive the same master secret and session keys from this value.
6. Finished: Both client and server send a “Finished” message encrypted with the new session keys, confirming the handshake succeeded.

After this handshake, all data flows through symmetric encryption using the negotiated session keys.

In TLS 1.3, this process is reduced to a single round trip. The client sends its key share in the first message, and the server responds with its key share and the encrypted handshake in one step.

TLS Handshake vs. TCP Handshake

To clear up one common point of confusion, the TLS handshake is not the same as the TCP three-way handshake. The TCP handshake (SYN, SYN-ACK, ACK) establishes a network connection. The TLS handshake runs on top of that connection to negotiate encryption. Both must complete before secure data transfer begins.

What Is a TLS Certificate?

A TLS certificate (also called an SSL certificate or X.509 certificate) is a digital document that binds a domain name to a public key. A trusted Certificate Authority (CA) signs the certificate, vouching for the server’s identity.

A TLS certificate contains:

• Subject — The domain name, such as securew2.com
• Public key — The server’s public key used during the TLS handshake
• Issuer — The certificate authority that signed the certificate
• Validity period — The start and expiration dates
• Signature — The CA’s digital signature that proves authenticity
• Serial number — A unique identifier used for revocation tracking

When a client connects to a TLS-secured server, it checks the certificate against its trust store. If the certificate is valid, unexpired, and signed by a recognized CA, the handshake proceeds. If verification fails, due to an expired cert, a domain mismatch, or an untrusted CA, the connection is rejected.

Certificate Types

Here are the key types of TLS certificates.

• Domain Validated (DV): Proves domain ownership only. Issued in minutes. Used for standard websites.
• Organization Validated (OV): Verifies the organization behind the domain. Requires identity checks.
• Extended Validation (EV): The highest validation level. Requires legal entity verification.
• Client certificates: Issued to devices or users rather than servers. Used in mutual TLS (mTLS) and EAP-TLS authentication for enterprise network access.

SSL vs. TLS: What Is the Difference?

Secure Sockets Layer (SSL) is the predecessor to TLS. Netscape developed SSL in the mid-1990s, and TLS 1.0 (defined in RFC 2246) replaced SSL 3.0 in 1999 after researchers found protocol-level vulnerabilities.

SSL vs TLS: Protocol Comparison

Feature	SSL 3.0	TLS 1.2	TLS 1.3
Year Released	1996	2008	2018
Status	Deprecated	Widely Supported	Current Standard
Handshake Round Trips	2	2	1
Forward Secrecy	No	Optional	Mandatory
Vulnerable to POODLE	Yes	No	No
Vulnerable to BEAST	Yes	Mitigated	No
Cipher Suite Flexibility	Limited	Broad	Streamlined

Despite the name difference, many people still refer to “SSL certificates” when they mean TLS certificates. The certificates themselves work with both protocols — the distinction is in the protocol version negotiated during the handshake.

All SSL versions (1.0, 2.0, 3.0) and TLS 1.0/1.1 are now deprecated. Modern deployments should support TLS 1.2 at minimum and TLS 1.3 where possible.

TLS 1.2 vs. TLS 1.3: Key Differences

TLS 1.3, published as RFC 8446 in August 2018, represents a significant overhaul of the protocol. As of 2025, approximately 75% of surveyed sites support TLS 1.3.

Performance

TLS 1.2 requires two round trips to complete the handshake before the client can send application data. TLS 1.3 reduces this to one round trip (1-RTT). TLS 1.3 also supports a 0-RTT mode for resumed connections, where the client sends encrypted data in the very first message — though 0-RTT trades some replay protection for speed.

Security

TLS 1.3 removed support for older, weaker algorithms, while requiring other features, as follows:

• Removed: RSA key exchange, CBC mode ciphers, RC4, SHA-1, MD5, arbitrary Diffie-Hellman groups, export-grade ciphers, static DH/ECDH
• Required: Forward secrecy via ephemeral Diffie-Hellman (DHE) or elliptic curve Diffie-Hellman (ECDHE)
• Only AEAD ciphers: All supported cipher suites in TLS 1.3 use Authenticated Encryption with Associated Data — meaning encryption and integrity verification happen in a single operation

Forward secrecy is mandatory in TLS 1.3. If a server’s long-term private key is compromised in the future, previously recorded sessions cannot be decrypted because each session used a unique ephemeral key pair.

Cipher Suites

TLS 1.2 supported dozens of cipher suites, many of which were insecure. TLS 1.3 reduced the list to five:

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

This simplification eliminates misconfiguration risk. Administrators no longer need to manually disable weak ciphers or worry about downgrade attacks targeting legacy algorithms.

The Role of Encryption Keys in TLS

TLS encryption relies on multiple key types working together:

Public and Private Keys (Asymmetric)

Every TLS certificate pairs a public key with a corresponding private key. The public key is shared openly in the certificate. The private key stays on the server and never leaves.

During the handshake, the client uses the server’s public key to encrypt the pre-master secret (TLS 1.2) or to verify the server’s signature on the key exchange (TLS 1.3). Only the server’s private key can decrypt or produce these values, which proves the server’s identity.

Session Keys (Symmetric)

After the handshake, both sides derive identical session keys from the shared secret. These session keys encrypt and decrypt all application data using fast symmetric algorithms like AES-256-GCM.

Session keys are ephemeral — generated fresh for every connection and discarded when the session ends. This limits the exposure window if a key is ever compromised and supports forward secrecy.

TLS Encryption Use Cases

Here are some of the most common use cases for TLS encryption.

Web Traffic (HTTPS)

HTTPS leverages TLS to wrap standard web traffic in a layer of robust encryption, ensuring that data exchanged between users and servers remains private and untampered. As of April 2025, over 90% of pages loaded in Chrome use HTTPS. Search engines also use HTTPS as a ranking signal.

Email Encryption

SMTP servers use STARTTLS to upgrade plaintext email connections to TLS-encrypted channels. This protects email content and credentials in transit between mail servers.

VPN and Remote Access

Many VPN protocols (OpenVPN, SSTP, WireGuard’s handshake) use TLS or TLS-like constructs to authenticate endpoints and establish encrypted tunnels.

Enterprise Wi-Fi Authentication (EAP-TLS)

This is where TLS encryption intersects directly with enterprise network security. EAP-TLS is an IEEE 802.1X authentication protocol that uses TLS to mutually authenticate both the client device and the RADIUS server using X.509 certificates.

Unlike password-based protocols like PEAP-MSCHAPv2 or EAP-TTLS/PAP, EAP-TLS does not transmit any credentials over the air. Both sides present certificates during a full TLS handshake inside an EAP tunnel. This eliminates the risk of credential theft, phishing, and man-in-the-middle attacks on Wi-Fi networks.

EAP-TLS combined with WPA2-Enterprise or WPA3-Enterprise provides the highest level of wireless network security available under the 802.1X standard.

RadSec: RADIUS over TLS

Traditional RADIUS traffic between access points and the RADIUS server uses UDP with limited encryption (only the shared secret is hashed). RadSec (RADIUS over TLS, defined in RFC 6614) wraps the entire RADIUS conversation in a TLS tunnel, providing full encryption and mutual authentication for the RADIUS transport itself.

RadSec is increasingly adopted in multi-site deployments and Eduroam environments where RADIUS traffic crosses untrusted networks.

Implementing TLS Encryption

While standard web servers rely on public trust to secure internet traffic, enterprise environments leverage the protocol internally to provide robust identity verification for users and devices.

TLS Implementation for Web Servers

1. Obtain a TLS certificate from a publicly trusted CA (or use ACME-based automation like Let’s Encrypt). 2. Install the certificate and private key on your web server. 3. Configure the server to support TLS 1.2 and TLS 1.3 only. 4. Disable legacy protocols (SSL 3.0, TLS 1.0, TLS 1.1) and weak cipher suites. 5. Enable HSTS (HTTP Strict Transport Security) to prevent protocol downgrade attacks.

TLS Implementation for Enterprise Network Authentication

Deploying EAP-TLS for Wi-Fi and VPN authentication requires a Private CA (not a public CA) to issue client certificates to devices and users. This involves:

• A managed PKI to issue, renew, and revoke X.509 client certificates
• A RADIUS server to perform EAP-TLS authentication against the certificates
• An MDM or onboarding solution to distribute certificates to managed and BYOD devices

Organizations that lack dedicated PKI staff often choose a turnkey managed PKI solution that integrates with their existing Identity Provider (Entra ID, Okta, Google Workspace) and MDM (Intune, Jamf, Kandji).

47-Day TLS Certificates: What IT Teams Need to Know

In April 2025, the CA/Browser Forum approved Ballot SC-081v3, which phases in shorter maximum TLS certificate lifetimes, on the following timeline:

• March 2026: 200-day maximum validity
• March 2027: 100-day maximum validity
• March 2029: 47-day maximum validity

This change affects every organization that uses publicly trusted TLS certificates. Manual certificate renewal at these intervals is impractical, so automation becomes mandatory. Organizations that already use ACME-based issuance and automated certificate lifecycle management will adapt smoothly. Those still managing certificates manually face significant operational risk.

For enterprise Wi-Fi and VPN certificates issued by a private CA, these public CA rules do not apply directly. However, the industry trend toward shorter certificate lifetimes and automated lifecycle management reinforces the value of a managed PKI that handles issuance, renewal, and revocation without manual intervention.

Extend TLS Security to Your Network with SecureW2 Certificate-Based Authentication

TLS encryption secures web traffic, email, and remote access. The same cryptographic foundation can protect your Wi-Fi and VPN infrastructure.

SecureW2 JoinNow Dynamic PKI automates the issuance, renewal, and revocation of X.509 certificates for EAP-TLS authentication. Paired with JoinNow Cloud RADIUS, every Wi-Fi and VPN connection is authenticated against real-time identity data from your directory, not with shared passwords that can be phished or stolen.

The platform integrates with Entra ID, Okta, Google Workspace, Intune, Jamf, and Kandji. BYOD users self-enroll through JoinNow MultiOS in under a minute, with no IT tickets required.

Schedule a demo to see how certificate-based network authentication eliminates credential theft and simplifies access management.

---

Frequently Asked Questions

Is TLS the same as SSL?

No. TLS is the successor to SSL. All SSL versions have been deprecated due to known vulnerabilities. The terms are sometimes used interchangeably (as in "SSL certificate"), but modern encrypted connections use TLS 1.2 or TLS 1.3.

What port does TLS use?

TLS itself does not define a port . Instead, it wraps the underlying application protocol. HTTPS uses port 443. SMTPS uses port 465. IMAPS uses port 993. RadSec uses port 2083.

Is TLS encryption end-to-end?

TLS encrypts data between two endpoints (client and server). It is point-to-point encryption, not end-to-end in the messaging sense. If a TLS connection terminates at a load balancer or reverse proxy, data may be decrypted and re-encrypted before reaching the origin server.

What is mutual TLS (mTLS)?

Standard TLS authenticates only the server. Mutual TLS (mTLS) requires both the server and the client to present certificates. This is the model used in EAP-TLS network authentication, where devices prove their identity with client certificates before gaining network access.

Does TLS operate at Layer 4 or Layer 7?

TLS sits between Layer 4 (Transport) and Layer 7 (Application) in the OSI model. It relies on a TCP connection (Layer 4) but operates above it, encrypting application-layer data before transmission.