What is TLS (Transport Layer Security)?
Updated: 3 days ago
TLS (Transport Layer Security) is a security protocol that creates an authenticated, encrypted channel between communicating applications. It is widely used to protect data in transit on the internet, including HTTPS web traffic, APIs, email and many other client-server connections. TLS is designed to prevent eavesdropping, detect tampering and authenticate the server; it does not prove that the server itself is trustworthy or protect data after it leaves the TLS endpoints.
The important distinction is that TLS protects a connection between endpoints. It is not the same thing as HTTPS, a VPN or encryption at rest. HTTPS is HTTP carried over TLS, while a VPN can protect a broader set of network traffic by tunnelling it to a VPN endpoint.
How does TLS work?
TLS sits between an application protocol and the underlying transport connection. In the common TCP case, a client first reaches the server, then the TLS handshake negotiates cryptographic parameters, authenticates the server and establishes shared traffic keys. Application data can then be protected with authenticated encryption.
The client starts the TLS handshake and advertises the TLS versions and cryptographic capabilities it supports.
The server selects compatible parameters and, in the usual public-internet case, presents a certificate containing its identity and public-key information.
The client validates the certificate and proves that the server possesses the corresponding private key through the handshake.
The peers establish shared secret material and derive separate traffic keys.
Protected application data is exchanged using authenticated encryption so interception does not reveal the plaintext and unauthorised modification can be detected.
The current IETF specification for TLS 1.3 is RFC 9846, published in 2026. It obsoletes RFC 8446 while retaining the TLS 1.3 protocol and incorporating accumulated updates and corrections.
What does TLS protect?
Confidentiality: protected application data is encrypted so an observer on the network cannot simply read the plaintext.
Integrity: authenticated encryption allows the endpoints to detect unauthorised modification of protected records.
Server authentication: the client can validate that it is communicating with the holder of the private key associated with the server certificate and requested identity.
Optional client authentication: some deployments use client certificates so the server can cryptographically authenticate the client as well.
TLS protects data in transit between its endpoints. If a browser establishes TLS to a website, the browser and the website or terminating service are the endpoints. If a CDN, reverse proxy or load balancer terminates TLS first, a separate protected connection may be needed between that service and the origin.
What is the TLS handshake?
The TLS handshake is the setup phase that creates the secure channel. In TLS 1.3, the handshake was simplified compared with older versions and is designed to establish fresh keys efficiently while removing obsolete cryptographic choices.
Why certificates matter
A certificate binds an identity, such as a domain name, to public-key information and is signed within a certificate trust chain. A browser does not merely check that a certificate exists: it checks relevant identity, validity and trust conditions. A certificate warning therefore means the browser could not establish the expected trust relationship and should not be casually ignored.
What is mutual TLS (mTLS)?
Ordinary public HTTPS normally authenticates the server to the client. Mutual TLS adds client-certificate authentication, so both sides authenticate cryptographically. The UK NCSC specifically identifies mTLS as an option for private or small-community APIs where two-way authentication is appropriate.
TLS 1.2 vs TLS 1.3
TLS 1.2 can still provide strong protection when it is correctly configured with modern cipher suites. TLS 1.3 removes older cryptographic options, changes the handshake and reduces the amount of legacy configuration that can be negotiated.
TLS 1.3: the current protocol version; designed around modern cryptography and a simplified handshake.
TLS 1.2: still widely deployed and capable of strong protection when configured correctly.
TLS 1.1 and TLS 1.0: formally deprecated and should not be used.
SSL: the predecessor to TLS. SSL versions are deprecated and insecure; calling modern TLS 'SSL' is common shorthand but technically inaccurate.
The NCSC guidance on using TLS to protect data recommends TLS 1.3 and/or TLS 1.2 with appropriate secure profiles, and recommends disabling deprecated TLS 1.1 and 1.0.
Is TLS the same as HTTPS?
No. TLS is the security protocol; HTTPS is HTTP communicated over a TLS-protected connection. The distinction matters because TLS can protect protocols other than HTTP. For a deeper web-specific explanation, see What is HTTPS (Hypertext Transfer Protocol Secure)?.
Is TLS the same as a VPN?
No. TLS normally protects an application connection between specific endpoints. A VPN (Virtual Private Network) can route selected or all device traffic through a separate tunnel to a VPN endpoint. VPN technologies such as OpenVPN can themselves use TLS as part of their control or authentication design, but TLS and VPN are not interchangeable concepts.
Where is TLS used?
HTTPS websites and web applications.
APIs carrying application data between clients and services.
Email protocols when configured to use TLS.
Database and application connections that support TLS.
Reverse proxies, load balancers and service-to-service connections.
Some VPN and remote-access systems as part of their secure connection design.
What can your ISP see when you use TLS?
TLS encrypts protected application content, but it does not make the network path invisible. Your broadband provider still carries the packets and can observe connection metadata such as source and destination IP addresses, timing and traffic volume. Depending on DNS configuration and protocol features, other information may also be exposed outside the encrypted application data.
TLS therefore should not be described as an anonymity system. It protects the content and integrity of a particular secure connection; it does not conceal every piece of metadata generated by using the internet.
Techie Broadband connection-path analysis
A useful way to understand TLS is to follow one HTTPS connection from a home device to a website. The security boundary is easier to see when the path is separated into layers.
Device: the browser or application creates the TLS connection and holds the session keys.
Home router and WiFi or Ethernet: these carry encrypted TLS records but do not normally need the website's plaintext.
UK broadband access network and ISP: these route the packets and can observe network-level metadata, but correctly protected TLS application content remains encrypted.
Internet transit: intermediate networks forward the encrypted packets.
TLS endpoint: the server, CDN or other terminating service decrypts the protected application data because it is one endpoint of the TLS connection.
Practical implication: upgrading from FTTC to FTTP, GPON or XGS-PON changes the access network and available performance, but it does not change the fundamental TLS trust model. TLS security depends on the endpoints, protocol version, cryptography, certificate validation and implementation quality rather than the retail broadband access technology.
Does TLS slow down broadband?
TLS adds handshake work, encryption, authentication and a small amount of protocol overhead. On modern hardware, that overhead is usually modest for ordinary browsing, but it can become measurable on very high-throughput links, overloaded servers, low-powered routers or embedded devices, and workloads that create large numbers of short-lived connections.
On multi-gigabit broadband, the bottleneck may move away from the access line to CPU performance, cryptographic acceleration, the application, the remote server, WiFi or Ethernet interface rates. A slow encrypted download is therefore not evidence that TLS itself is the limiting factor.
What TLS does not protect against
Phishing: a fraudulent site can still use a valid TLS certificate for a domain it controls.
Malware: TLS can encrypt malicious traffic just as it encrypts legitimate traffic.
Unsafe content: encryption does not make the content trustworthy.
Compromised endpoints: TLS cannot protect plaintext after a compromised client or server has legitimately decrypted it.
Account tracking: websites can still identify signed-in users and use application-level identifiers.
Traffic analysis: packet sizes, timing and network destinations can reveal metadata even when application content is encrypted.
Common TLS problems and how to troubleshoot them
Check the device date and time. Incorrect clocks can make otherwise valid certificates appear expired or not yet valid.
Read the certificate warning rather than bypassing it. Confirm the hostname and the reason validation failed.
Update the browser, operating system, application and server software so current TLS versions and security fixes are available.
If you manage the server, confirm the certificate chain, hostname coverage and expiry date.
Check which TLS versions and cipher suites the client and server actually support. A legacy client may fail against a modern server, while an outdated server may offer deprecated protocols.
Test from another device or network to separate a local device problem from a server-side problem.
If a proxy, firewall, security appliance or CDN terminates or inspects TLS, check each TLS leg separately rather than assuming one end-to-end session.
Only after local and server configuration checks should you investigate wider routing, DNS or broadband connectivity problems.
Common TLS misconceptions
A padlock means the website is safe: false. It means the connection passed the browser's TLS checks; it does not endorse the site's content or operator.
TLS hides everything from the ISP: false. Protected content is encrypted, but network metadata remains visible.
TLS and SSL are the same: not technically. SSL is obsolete; modern secure connections use TLS.
TLS 1.3 makes TLS 1.2 automatically unsafe: false. Properly configured TLS 1.2 can still provide strong protection, although migration to TLS 1.3 is preferred where practical.
Faster broadband makes TLS stronger: false. Access speed and cryptographic security are separate properties.
Frequently asked questions about TLS
What does TLS stand for?
TLS stands for Transport Layer Security.
Is TLS encryption?
TLS uses encryption, but it is more than an encryption algorithm. It is a protocol that negotiates cryptographic parameters, authenticates endpoints and protects application data with confidentiality and integrity.
Is TLS 1.3 the latest version?
Yes. TLS 1.3 is the current protocol version. In 2026 the IETF published RFC 9846 as the current TLS 1.3 specification, obsoleting RFC 8446.
Should TLS 1.0 and 1.1 still be used?
No for normal modern deployments. TLS 1.0 and 1.1 are formally deprecated. Current UK NCSC guidance recommends TLS 1.3 and/or properly configured TLS 1.2 and disabling deprecated versions.
Can TLS protect IPv4 and IPv6 connections?
Yes. TLS operates above the IP layer and can protect application connections carried over either IPv4 or IPv6. The IP version affects routing and addressing, not the core TLS security model.
Key takeaway
TLS is the protocol that creates a protected channel between applications across an untrusted network. Its job is to encrypt protected data in transit, detect tampering and authenticate the server, with optional client authentication. TLS 1.3 is the current version, while properly configured TLS 1.2 remains widely used. The key limitation is just as important: TLS secures the connection between endpoints; it does not make the endpoint, website or content inherently trustworthy.
To explore the related technical concepts used in this TLS (Transport Layer Security) guide, visit our broadband terminology guide.
