What is TLS?

Published Aug 13, 2026

← All glossary terms Jump to T

Transport Layer Security (TLS) is a cryptographic protocol that secures data moving between two endpoints – most visibly, the padlock icon in a browser’s address bar. A handshake authenticates the parties and negotiates encryption keys; the record protocol that follows then encrypts and integrity-checks every byte exchanged over the connection.

Key takeaways

  • TLS secures data in transit for HTTPS, APIs, VPNs, and client tunnels.
  • A handshake authenticates peers and negotiates keys before any data flows.
  • TLS 1.3 is the current standard; TLS 1.0 and 1.1 are deprecated.
  • SSL is TLS’s deprecated predecessor; the names are often used interchangeably.
  • Versa SASE clients can use TLS as a tunnel transport to secure access gateways.

On this page: Why it mattersHow it worksTypesTLS & VersaFAQ

Why is TLS important?

TLS is the protocol that makes the modern web trustworthy. Every HTTPS connection – every login form, every payment page, every API call between two services – depends on TLS to encrypt data in transit and prove that the server on the other end is who it claims to be. Without it, anyone on the network path could read or alter traffic passing between client and server.

Its importance extends well past browsers: TLS secures email transfer, VPN and remote-access tunnels, and service-to-service traffic inside modern application architectures. Because it is a well-specified, open standard, clients and servers from different vendors interoperate without custom integration work. Browsers and security tooling increasingly treat unencrypted connections as actively unsafe – flagging plain HTTP, requiring valid certificates – making TLS close to mandatory for any internet-facing service.

What is TLS?

TLS works in two phases. The handshake establishes trust and shared secrets: the client and server agree on a TLS version and cipher suite, the server presents a certificate proving its identity (validated back to a trusted certificate authority), and both sides derive a shared session key – using Diffie-Hellman key exchange in modern TLS, so a future key compromise cannot decrypt a recorded past session.

Once the handshake completes, the record protocol takes over: it encrypts application data, divides it into segments, and attaches an integrity check to each one, so tampering or replay is detectable. TLS runs on top of TCP and sits below the application protocol – HTTP, SMTP, or a custom protocol – which is why it secures so many kinds of traffic without those protocols themselves needing to change.

Types of TLS

Four major versions have shipped. TLS 1.0 and TLS 1.1 are deprecated – major browsers withdrew support by 2020, and the IETF formally deprecated both in RFC 8996 (2021) because of known weaknesses. TLS 1.2 remains common and is secure when configured with modern cipher suites, but it still permits older, weaker options unless restricted. TLS 1.3 (RFC 9846, which consolidated and obsoleted the original RFC 8446) is the current standard: it shortens the handshake, removes legacy ciphers entirely, and makes forward secrecy mandatory.

Beyond versions, two modes matter. Standard TLS authenticates only the server, which is sufficient for most web traffic. Mutual TLS (mTLS) additionally requires the client to present a certificate, authenticating both sides – common in Zero Trust architectures. A connectionless sibling, DTLS, adapts the same concepts to UDP transports, where TCP’s overhead is unwanted – a fit for VPN tunnels and real-time traffic. A cipher suite is the negotiated bundle of algorithms – key exchange, encryption, and integrity check – a given TLS session actually uses.

TLS & Versa

A Versa SASE client can reach a secure access gateway over TLS, alongside IPsec and DTLS, as one of the tunnel transports in its configured tunnel order. Administrators set TLS parameters directly on the Secure Access Service gateway object: minimum and maximum supported TLS version (TLS 1.0 through TLS 1.3), an allowed list of TLS cipher suites, the TLS listening port (443 by default), and a TLS profile ID tying the tunnel to its certificate and key material. This version range is what the gateway configuration surface exposes; the SSL VPN profile documentation separately describes its tunnels as TLS 1.2, so check which surface governs your deployment when hardening versions.

The same TLS tab and tunnel-order options appear whether the gateway is configured for Secure SD-WAN or NGFW deployments, keeping the TLS model consistent across Versa’s secure access architectures. Restricting the minimum version to TLS 1.2 or higher, and trimming the cipher suite list, are the levers administrators use to harden a gateway’s TLS posture without touching its IPsec or DTLS options.

Frequently asked questions

What is the difference between TLS and SSL?

SSL is TLS’s predecessor; all SSL versions are now deprecated and considered insecure. TLS 1.0 began as a minor update to SSL 3.0, but the two have diverged since. “SSL” is still used informally to mean TLS – an “SSL certificate” is really a TLS certificate.

What is the difference between TLS and DTLS?

TLS runs over TCP and assumes a reliable, ordered byte stream. DTLS adapts the same concepts to UDP, adding its own handling for packet loss and reordering, which makes it suitable for VPN tunnels and real-time traffic where TCP’s overhead is unwanted.

What is mutual TLS (mTLS)?

Mutual TLS extends the standard handshake so both the client and the server present certificates, authenticating each other rather than only the server. It is common in service-to-service communication and Zero Trust architectures, where every connection must prove both endpoints’ identity.

Why were TLS 1.0 and 1.1 deprecated?

TLS 1.0 and 1.1 rely on older cryptographic algorithms and handshake mechanics with known weaknesses, including susceptibility to certain downgrade attacks. Major browsers removed support in 2020, and the IETF formally deprecated both versions in RFC 8996 (2021), pushing the ecosystem toward TLS 1.2 and the stronger TLS 1.3.

What port does TLS use?

TLS itself is not tied to a single port; the port depends on the application protocol layered on top of it. HTTPS conventionally uses port 443, and Versa secure access gateways use the same default, though administrators can configure a different value.

More on TLS

If you want to learn more, these are sources we trust.

RFC 9846: TLS 1.3 RFC 5246: TLS 1.2
The current IETF standard (obsoletes RFC 8446): handshake, record protocol, and the mandatory forward-secrecy design that replaced TLS 1.2’s optional one. The historic TLS 1.2 standard, still widely deployed; defines the cipher suite negotiation TLS 1.3 later simplified.

If you’re reading about TLS, these are worth looking at next.

Secure Sockets Layer Versa SASE Client CA Chain
TLS’s deprecated predecessor; the name is still used informally to describe TLS connections and certificates. Versa’s endpoint client, which can establish TLS tunnels – alongside IPsec and DTLS – to reach secure access gateways. The chain of certificate authorities a TLS handshake validates a server certificate against, up to a trusted root.