EMZETT.TLS
In short: “Transport Layer Security” — the protocol that enables encrypted and authenticated connections on the internet, e.g. with HTTPS. Successor to SSL.
In more detail: TLS runs between the transport and application layers and provides three things: confidentiality (encryption of data), integrity (detecting tampering) and authenticity (proof of the server’s identity via a certificate). The connection is established via the TLS handshake, during which client and server agree on a cipher suite and exchange keys. The actual data transfer after the handshake runs over the TLS Record Protocol.
In Depth
The TLS handshake runs (simplified, TLS 1.3) through a few steps before any payload data flows at all:
Client -> Server: ClientHello (supported cipher suites, random number)
Server -> Client: ServerHello + certificate + key exchange data
Client: checks the certificate against trusted CAs (certificate chain)
Client & Server: jointly derive a session key from this
From now on: all data runs encrypted over the TLS Record Protocol
TLS 1.3 (the current standard) completes this handshake in just a single round trip (one back-and-forth between client and server), while TLS 1.2 still needed two rounds for it — this makes every new connection setup noticeably faster, which adds up meaningfully with many short HTTPS requests (typical for modern websites with many assets).
A central misconception: TLS protects the TRANSMISSION between client and server, not the data before or after. A form submitted via HTTPS is protected during transmission — but once the data arrives on the server and, say, ends up unencrypted in a database, TLS no longer applies; that needs additional encryption “at rest” (see Encryption). Likewise, TLS doesn’t protect against the server itself (or whoever has access to it) being able to view the plaintext data — TLS only prevents a third party from reading along ON THE WAY.
Mutual TLS as an extension
In a normal TLS handshake, only the server identifies itself via a certificate, while the client initially remains anonymous (the actual authentication of the user typically happens later, at the application level, e.g. via a login form). With “mutual TLS” (mTLS), BOTH sides identify themselves via a certificate — common in machine-to-machine communication between internal services, where not only the server but also the requesting client has to be cryptographically identified beyond doubt before a connection is even established. In microservice architectures, mTLS is often managed automatically via a “service mesh” (e.g. Istio), so that every internal service automatically gets its own short-lived certificate, without developers having to manually maintain certificate management.
Other protocols over TLS
TLS isn’t limited to HTTPS — practically every protocol that was originally designed unencrypted now has a TLS-secured variant: SMTP-over-TLS for encrypted email transmission between mail servers, FTPS as an encrypted variant of old FTP, or LDAPS for encrypted directory service queries. The pattern is always the same: the original application protocol remains unchanged in content, but runs entirely within a TLS-encrypted connection instead of directly and unencrypted over TCP — one reason why TLS is often described as its own, universal “security layer” that can practically be added retroactively to any existing protocol.
0-RTT for returning connections
TLS 1.3 introduces a further speedup called “0-RTT” (Zero Round Trip Time), for connections to a server with which a session has already recently existed: when reconnecting, the client can already send encrypted payload data in its very first message, without waiting for a response from the server. This saves an entire round trip and noticeably speeds up repeated connections, but brings a subtle security risk with it: without additional protective measures, an attacker could replay an intercepted 0-RTT message a second time (replay attack) — servers that support 0-RTT therefore have to make sure themselves that a replayed request doesn’t trigger harmful duplicate effects (e.g. no duplicate payment charge).