• Glossary
  • What is TLS (transport layer security)?

Security glossary

What is TLS (transport layer security)?

Transport layer security (TLS) is a cryptographic protocol that provides confidentiality, integrity and endpoint authentication for data sent between two applications over a network. It runs above a reliable transport such as TCP, uses certificates to authenticate servers, and protects traffic for HTTPS, email and DNS over TLS.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

Transport Layer Security (TLS) is a cryptographic protocol that encrypts and authenticates data between applications over networks, with TLS 1.3 (RFC 8446) removing legacy features to ensure forward secrecy and protect enterprise traffic including HTTPS, email, and DNS over TLS. Poor TLS management causes outages and security exposure through expired certificates, outdated protocol versions, and unmanaged private keys, requiring organizations to maintain certificate inventories, automate renewals, and enforce minimum protocol version policies. DNS over TLS (RFC 7858) specifically encrypts DNS queries on TCP port 853 to prevent query interception, while DNS over HTTPS carries DNS inside standard HTTPS traffic on port 443, with each approach offering different visibility and deployment trade-offs for network administrators.

  • TLS 1.3 eliminated static RSA key exchange and legacy algorithms, guaranteeing forward secrecy so that recorded sessions cannot be decrypted even if a server key is later stolen.
  • DNS over TLS operates on dedicated TCP port 853 and is easier for network operators to identify, monitor, and control compared to DNS over HTTPS which blends with standard web traffic on port 443.
  • Certificate management failures—including expiration without renewal, incomplete certificate chains, and hostname mismatches—are common causes of service outages and client authentication errors across load balancers, APIs, and embedded devices.

TLS at a glance

AttributeValue
Full nameTransport layer security
CategoryCryptographic network protocol
Defined inRFC 8446 for TLS 1.3 and RFC 5246 for TLS 1.2
Protocol and portRuns over TCP; DNS over TLS uses TCP port 853 as defined in RFC 7858
OSI layerCommonly placed between the transport and application layers
Primary useEncrypting and authenticating application traffic such as HTTPS, email and DNS over TLS
Related termsDNS over TLS, DNS over HTTPS, DNSSEC, Public key infrastructure, Certificate authority

How TLS works

TLS begins with a handshake in which the client and server agree on protocol parameters, authenticate the server and derive shared session keys. After the handshake, application data is sent in encrypted and integrity-protected records.

  1. Client hello: The client opens a TCP connection and sends the TLS versions, cipher suites and key exchange information it supports.
  2. Server hello and certificate: The server selects the parameters and sends its certificate so the client can check its identity.
  3. Certificate validation: The client verifies that the certificate chains to a trusted certificate authority, has not expired and matches the requested name.
  4. Key exchange: Both sides use an ephemeral key exchange to derive the same session keys without sending them over the network.
  5. Encrypted application data: The endpoints switch to the negotiated cipher and exchange application data in protected records.

TLS 1.3, defined in RFC 8446, shortens the handshake and removes older, weaker algorithms. Mutual TLS adds a client certificate so the server can authenticate the client as well. The steps above show the common server-authenticated case.

Why TLS matters in enterprise networks

TLS protects most traffic on enterprise networks, including web applications, APIs, email and management interfaces. Without it, anyone with access to the path can read or alter data in transit. TLS 1.3, published as RFC 8446, removed legacy features such as static RSA key exchange, so every session uses forward secrecy and a recorded session cannot be decrypted later with a stolen server key.

TLS also matters for core network services. DNS over TLS, defined in RFC 7858, encrypts queries between a client and a resolver on TCP port 853, which keeps names that users look up from being read on the path. It differs from DNS over HTTPS, which carries DNS inside HTTPS on the standard web port. Encryption also changes monitoring, because tools that relied on inspecting plain text DNS need other ways to see the traffic.

Poor TLS management causes outages and exposure. Expired certificates stop services, outdated protocol versions and weak cipher suites invite downgrade attacks, and unmanaged private keys let attackers impersonate servers. Teams need an inventory of certificates, automated renewal, and a policy that sets minimum protocol versions across all services.

TLS vs DNS over HTTPS

DNS over TLS carries DNS messages directly inside a TLS session on a dedicated port, while DNS over HTTPS wraps them in HTTP requests inside a TLS session on the standard HTTPS port.

AttributeTLSDNS over HTTPS
StandardRFC 7858RFC 8484
TransportTLS over TCPHTTP over TLS
Default portTCP 853TCP 443
Visibility to network operatorsEasy to identify and to block or monitor by portBlends with other HTTPS traffic, so harder to separate
Typical implementation pointOperating system or resolverOften the browser or application

Common TLS issues

A certificate that expires without renewal causes browser warnings and failed API calls, often at an unexpected hour. Services with many endpoints, such as load balancers and management interfaces, are most often missed.

A server that sends only its own certificate and omits the intermediate works in some browsers but fails in command-line tools, Java clients and embedded devices. Testing from several client types exposes the gap.

Clients reject a certificate when the requested hostname is not in the subject alternative name field. This commonly appears when a service is reached by IP address or by a new alias that the certificate does not cover.

Older clients that support only TLS 1.0 or 1.1, or servers that disable the ciphers a client offers, fail with handshake errors. Packet captures usually show an alert right after the client hello.

DNS over TLS clients fail or fall back to unencrypted DNS when a firewall blocks TCP port 853. The result is either broken resolution or silent loss of encryption, depending on client settings.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

TLS FAQ

Related terms

Article

SSL (secure sockets layer)

Security technology for establishing an encrypted link between a server and a client.

Learn more
Article

DNSSEC (Domain Name Service Security Extension)

A mechanism that uses cryptography to provide authentication and integrity for DNS queries.

Learn more
Article

TCP

A protocol that provides reliable, ordered, and error-checked delivery of bytes between applications running on hosts communicating via an IP network; part of the TCP/IP suite.

Learn more
Article

DNS – Domain Name System

A hierarchical naming system that enables communication across devices in a network.

Learn more
Article

DNS tunneling

Exploits the DNS protocol to tunnel malware and other data through a client-server model.

Learn more
Article

OSI model

A conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system.

Learn more
Article

DNS hijacking

IP addresses of your domain’s DNS servers are changed to IP addresses of attacker-controlled servers.

Learn more
Article

DNS server

Also called a DNS nameserver, it stores DNS records and responds to and resolves DNS queries from devices. Learn More

Learn more
Browse the full glossary