TLS/SSL

TLS is the standard protocol for encrypted connections on the internet and the technical successor to the historical SSL. This article explains how the handshake works, what role certificates play, when mTLS makes sense, and how transport encryption differs from a VPN.

Every visit to a website with https, every API request between services, almost every email delivery: in the background, Transport Layer Security is at work. TLS encrypts connections over insecure networks and is therefore one of the most widely used security technologies of all. Nevertheless, the name of its predecessor, SSL, persists stubbornly in everyday language, and in many environments protocol versions that have long been considered insecure are still running.

What is TLS/SSL?

TLS (Transport Layer Security) is a protocol for encrypting connections at the transport layer. It protects the confidentiality and integrity of transmitted data and proves the identity of the other party through certificates. Its predecessor SSL (Secure Sockets Layer) was developed in the 1990s. Its versions have long been considered broken and were officially retired, SSL 3.0 as early as 2015.

The term SSL lives on above all in the word SSL certificate. Technically, these are X.509 certificates used with TLS. The currently recommended versions are TLS 1.2 and TLS 1.3; versions 1.0 and 1.1 were officially declared obsolete in 2021. TLS 1.3 has significantly streamlined the protocol structure, removed old cryptographic methods, and sped up the connection setup.

How does TLS work?

Before payload data flows, both sides negotiate the parameters of the connection in the handshake:

Negotiation: Client and server agree on the protocol version and cipher suite, that is, the concrete cryptographic methods. In TLS 1.3 this succeeds in a single round, which noticeably shortens the connection setup.
Certificate verification: The server proves its identity with an X.509 certificate signed by a certificate authority (CA). The client checks the signature chain up to a trusted root, the hostname, and the validity period.
Key exchange: Using an asymmetric method, today usually ephemeral Diffie-Hellman, both sides generate shared session keys. The keys are short-lived, which keeps recorded traffic protected even if a private key is compromised later (forward secrecy).
Symmetric encryption: The actual data is secured by fast symmetric methods such as AES-GCM, which combine encryption and integrity protection.
Optional mTLS: With Mutual TLS, the client additionally presents a certificate. Both sides authenticate each other, which makes mTLS the standard for service-to-service communication and API protection. The blog article on Mutual TLS offers a detailed explanation.

Why TLS matters

Protection on foreign paths: between client and server lie networks that no one controls, from hotel Wi-Fi to the transit provider. TLS makes eavesdropping and manipulation on these stretches practically ineffective.
Proof of identity: without certificate verification, any server could pose as online banking or a company portal. TLS binds the connection to a verified identity.
A compliance requirement: GDPR, PCI DSS, and industry-specific rules require encryption when transmitting sensitive data. Outdated protocol versions regularly turn up as findings in audits.
Visibility in the browser: browsers mark unencrypted pages as insecure. For publicly reachable services, HTTPS is therefore also a matter of external perception.
Certificates as an operational risk: expired certificates are among the most common causes of avoidable outages. Automated renewal and an inventory of all certificates are therefore part of basic operations.

Typical scenarios

A company migrates its customer portals to TLS 1.3 and disables versions 1.0 and 1.1. Old clients are identified beforehand so that the migration succeeds without surprises. A side effect: connection setup becomes faster, measurably so on mobile access.

Two partner companies couple their systems via an API. Instead of IP allowlisting and shared passwords, they rely on mTLS: only clients with a valid certificate reach the interface, every connection is authenticated on both sides and encrypted throughout.

In the internal data center, a platform for workload communication enforces TLS between all services. Even if an attacker gets into the network, the traffic between the applications remains unreadable to them.

TLS vs. VPN

Both technologies encrypt, but at different layers. TLS secures individual connections between two endpoints, typically per application: browser to web server, client to API. A VPN establishes a tunnel at the network layer and transports any traffic within it, for example between sites or from the end device into the company network.

The line blurs because many VPNs themselves use TLS as their transport. The practical difference lies in the scope: a classic VPN often grants broad network access once established, whereas TLS-based zero-trust access grants each application individually. Modern architectures therefore increasingly replace blanket tunnels with application-specific, TLS-secured access with identity verification.

How KAEMI helps

KAEMI implements transport encryption as an end-to-end architectural principle. As part of Application Security , KAEMI operates the TLS termination of exposed applications on the Cloudflare platform, including modern protocol configuration and automated certificate management. For site and cloud connectivity, Cloud Connectivity ensures that traffic to your cloud environments runs encrypted throughout and is cleanly authenticated. If you want to retire outdated protocol versions or introduce mTLS for your interfaces, you can reach the team via the contact page .

Frequently asked questions about TLS/SSL

What is the difference between SSL and TLS?

TLS is the successor to SSL. The SSL versions date from the 1990s, are considered broken, and were officially retired. Since 1999 the protocol has been developed further under the name TLS. The term SSL has persisted above all in the word SSL certificate; what is meant today are X.509 certificates used with TLS.

Which TLS version should be in use?

Recommended are TLS 1.2 with secure cipher suites and preferably TLS 1.3. Versions 1.0 and 1.1 were declared obsolete in 2021 and should be disabled, as should all SSL versions. Before switching them off, it is worth checking the access logs to find legacy systems that still use old versions.

What is an SSL certificate technically?

An X.509 certificate binds a public key to a name, usually a hostname. A certificate authority confirms this binding with its signature. During connection setup, the client checks the signature chain, the name, and the validity. Because certificates are time-limited, automated renewal and a central inventory are part of stable operations.

When is mTLS worthwhile?

Whenever both sides of a connection must be established beyond doubt: for APIs between companies, for service-to-service communication in microservice environments, and for zero-trust access by machines. mTLS replaces shared passwords and IP allowlisting with cryptographic identities. The prerequisite is orderly management of the client certificates, for example via an internal certificate authority with automation.

Does TLS replace a VPN?

Partly. TLS secures individual application connections, a VPN transports any traffic through a tunnel at the network layer. For remote access, the approaches are shifting: zero-trust models grant applications individually over TLS-secured, identity-verified connections and thereby replace broad VPN tunnels. For site coupling and special protocols, network tunnels continue to have their place.