What TLS Does, and What It Doesn't

Transport Layer Security (TLS) is the protocol that encrypts traffic between client and server. On the web, it's the S in HTTPS. TLS solves three tasks at the transport layer: confidentiality (the traffic is encrypted), integrity (tampering with the data stream is detected), and server authentication (the client verifies via certificate that it is really talking to the expected server). This protects against eavesdropping and man-in-the-middle attacks on the network path.

What matters for API security is the boundary: TLS says nothing about what an authenticated caller is allowed to do. It is purely transport protection, not application authorization. A call fully secured by TLS can still read someone else's object (BOLA), trigger a privileged function (BFLA), or get leaked fields back (BOPLA). Who you are and what this request is allowed to do is only settled by authentication and authorization within the application. TLS encrypts the tunnel, but it doesn't guard the door behind it.

AspectTLS (server auth)mTLS (mutual)
Who proves identityonly the server, to the clientserver and client, to each other
Typical usebrowser to web/API, public endpointsservice-to-service, M2M APIs, zero-trust networks
Certificatesserver certificate from a public CAadditionally client certificates, often from an internal CA
Protects againsteavesdropping, tampering, server spoofingadditionally: unknown/unauthorized callers
Operational overheadmoderate, established CA processeshigh: distribution and rotation of many client certificates (e.g. SPIFFE/SPIRE)
Replaces app authorizationnono, only settles identity, not permission

TLS and mTLS compared

TLS 1.2 and 1.3, Versions and Configuration

Two versions are currently relevant. TLS 1.3 (RFC 8446, 2018) is the state of the art: a faster handshake (often a single round trip), only strong cipher suites, and forward secrecy throughout. TLS 1.2 is still widely used and, with correct configuration, is considered secure; for compatibility it should usually be offered in parallel.

OWASP's recommendations for server configuration are unambiguous:

  • Disable TLS 1.0 and 1.1. Both were formally deprecated by RFC 8996 (March 2021), banned by PCI DSS, and removed from all major browsers. SSLv2 and SSLv3 should be disabled entirely.
  • Allow only strong cipher suites with forward secrecy, and remove weak, outdated ones.
  • Enable downgrade protection via the TLS_FALLBACK_SCSV extension, so attackers can't force a weaker version.
  • API endpoints should disable HTTP entirely and accept only encrypted connections. If that's not possible, unencrypted requests should be rejected rather than redirected, so no data is ever sent in plaintext.

For the German-speaking region, BSI TR-02102-2 specifies the permitted protocol versions, cryptographic procedures, and key lengths in detail; NIST maintains the parallel in SP 800-52 Rev. 2.

Certificates, PKI, and HSTS

Server authentication relies on X.509 certificates and a public key infrastructure (PKI). A certificate authority (CA) signs a server's certificate; the client trusts the server because it trusts the CA. During the handshake, the client checks the signature chain, the validity period, and whether the name (hostname) matches the certificate. Important: TLS only proves that the counterpart holds the private key to the presented, valid certificate, not that it behaves benignly.

A residual weakness remains: the first call to a domain can happen over unencrypted HTTP and be intercepted. HTTP Strict Transport Security (HSTS, RFC 6797) closes this gap. Via the response header, the server instructs the browser to only ever reach the domain over HTTPS from then on:

  • Strict-Transport-Security: max-age=63072000; includeSubDomains enforces HTTPS for the domain and all subdomains for two years.
  • The preload directive adds the domain to a list built into the browser itself, so that even the very first call happens encrypted. OWASP warns: preload can have lasting consequences, going back to HTTP is then barely possible.

HSTS is relevant for browser-based clients; pure API endpoints achieve the same effect by simply never serving HTTP in the first place.

mTLS: Mutual Authentication

With normal TLS, only the server authenticates itself. Mutual TLS (mTLS) turns this around for both sides: the client also presents a certificate, and the server checks it. By the end of the handshake, both parties have cryptographically proven their identity. That makes mTLS especially suited to service-to-service communication, where there is no human login: each service gets its own identity as a certificate.

Typical use cases:

  • Internal east-west traffic in microservice landscapes, often via a service mesh that enforces mTLS between services transparently.
  • Machine-to-machine APIs and partner integrations, where a client certificate serves as a strong, hard-to-forge credential, as an alternative or supplement to API keys and tokens.
  • Zero-trust networks, where the network itself no longer confers any trust (cf. NIST SP 800-207): every call must be authenticated, regardless of whether it comes from the internal network.

The distinction from the first section still applies here: mTLS answers the question of who is calling very strongly, but doesn't replace the functional authorization of what this caller is allowed to do. Identity and permission remain separate layers.

Certificate Rotation and SPIFFE/SVID

The bottleneck of mTLS in operations is not the cryptography, but the lifecycle management of certificates: issuing, distributing, keeping them short-lived, renewing them in time, and revoking compromised ones. Long-lived, manually distributed client certificates don't scale in dynamic environments and cause outages when a certificate expires unnoticed. The answer is short-lived certificates with automatic rotation: instead of revoking them, you let them expire quickly and keep issuing new ones.

SPIFFE (Secure Production Identity Framework for Everyone) standardizes this workload identity. Core building blocks:

  • A SPIFFE ID is a URI of the form spiffe://trust-domain/workload-identifier, for example spiffe://acme.com/billing/payments. It uniquely identifies a workload.
  • An SVID (SPIFFE Verifiable Identity Document) is the document with which a workload proves its identity, either as an X.509-SVID (certificate for mTLS) or as a JWT-SVID (token). It is considered valid if it was signed by an authority within the trust domain.

Implementations like SPIRE issue SVIDs automatically and rotate them on a short cycle, so every service gets its identity without any hardcoded secrets. SPIFFE is supported by, among others, Istio and Envoy, and forms the identity layer beneath a service mesh's mTLS.

Gateway Termination and the Relationship to the Gateway

In practice, TLS is rarely handled separately in every backend, it's usually terminated at the edge. An API gateway or reverse proxy takes over the TLS handshake, manages the certificates centrally, and relieves the services behind it. With pure TLS termination, encryption ends at the gateway, and traffic continues internally unencrypted. That's only acceptable if the internal network itself is considered trustworthy, a state that zero trust explicitly does not assume.

Two patterns follow from this:

  • TLS re-encryption / end-to-end: the gateway terminates the external connection and establishes a new, separate TLS or mTLS connection to the backend. That way, east-west traffic also stays encrypted and authenticated.
  • TLS passthrough: the gateway passes the encrypted stream through unchanged, and the backend terminates it itself. Useful when encryption must reach all the way to the service.

A gateway can also serve as a central enforcement point for mTLS at the perimeter, by checking partners' client certificates. As with any gateway control: this solves transport and coarse authentication, not object-level authorization within the service. Secure APIs need both, in the sense of defense in depth.

Sources

Keep reading
FundamentalsWhat Is an API Gateway? RisksBroken Authentication (API2) FundamentalsAPI Authentication