TLS & mTLS
How TLS 1.3 works end to end. What mTLS adds for mutual authentication, and why it matters for BFSI APIs.
What problem does TLS solve?
When a payment server calls a banking API over the internet, three things must hold:
- Confidentiality: no one on the network can read the request or response.
- Integrity: no one can modify the data in transit without detection.
- Authentication: the client is actually talking to the real server, not an impersonator.
TLS provides all three. Without it, an attacker on the same network can read transaction amounts, modify account numbers, or redirect traffic to a fake server (man-in-the-middle attack).
The TLS 1.3 handshake
TLS 1.3 reduced the handshake to 1 round-trip (down from 2 in TLS 1.2), removing weak cipher suites and mandatory forward secrecy. Here is what happens:
Client Server | | |--- ClientHello ------------------>| | supported cipher suites | | key share (ECDHE public key) | | | |<-- ServerHello --------------------| | chosen cipher suite | | key share (ECDHE public key) | | certificate | | CertificateVerify (signature) | | Finished (HMAC) | | | |--- Finished (HMAC) -------------->| | | |=== Encrypted application data ====|
The ECDHE key exchange means both sides contribute randomness to the session key. Even if the server's private key is later compromised, past sessions cannot be decrypted. This property is called forward secrecy.
The server's certificate is signed by a Certificate Authority (CA). The client checks this signature against its CA bundle to verify it is talking to a legitimate server.
TLS 1.2 vs TLS 1.3
TLS 1.2 is still widely used but carries legacy baggage: optional forward secrecy (some servers use RSA key exchange), weak cipher suites (RC4, 3DES, export ciphers), and a 2 round-trip handshake.
RBI and SEBI compliance note
RBI guidelines for digital payments (2021) and SEBI cybersecurity circulars recommend TLS 1.2 as minimum, with TLS 1.3 preferred for new integrations. Systems still accepting TLS 1.0 or 1.1 are non-compliant and should be upgraded immediately.Cipher suites
A cipher suite specifies the combination of algorithms used for key exchange, authentication, and encryption. TLS 1.3 reduced this to just 5 suites, all using AEAD encryption:
TLS_AES_256_GCM_SHA384 (preferred) TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 (mobile-friendly) TLS_AES_128_CCM_SHA256 TLS_AES_128_CCM_8_SHA256
In TLS 1.2, cipher suites also encoded the key exchange algorithm (RSA, ECDHE, DHE). Suites like TLS_RSA_WITH_AES_128_CBC_SHA use static RSA key exchange, which means no forward secrecy. Avoid these in any system you control.
mTLS: mutual TLS
Standard TLS only authenticates the server. The client verifies the server's certificate, but the server accepts any client. For most public-facing APIs, this is fine because authentication is handled at the application layer (API keys, OAuth tokens).
In mTLS, both sides present certificates. The server also verifies the client's certificate against a trusted CA. This creates a network-layer authentication layer independent of application credentials.
Standard TLS: Client verifies Server cert → Server identity confirmed Server does not verify Client → anyone can connect Mutual TLS (mTLS): Client verifies Server cert → Server identity confirmed Server verifies Client cert → Client identity confirmed at network level
mTLS is commonly used in:
- Bank-to-bank API integrations (NACH, IMPS gateway connections)
- NPCI connections for UPI participants
- Internal service-to-service communication (service mesh: Istio, Linkerd)
- Open Banking APIs under PSD2 (eIDAS certificates mandate mTLS)
- Cloudflare API Shield for protecting public-facing APIs
mTLS does not replace API authentication
mTLS proves which client is connecting at the transport layer. It does not replace application-level controls (authorization, rate limiting, input validation). Use both: mTLS for identity, application layer for access control.Certificate pinning
Certificate pinning is a technique where the client hard-codes the expected certificate (or its public key hash) rather than trusting any CA-signed certificate. If the server presents a different cert, the connection is rejected even if it is CA-valid.
This defends against a compromised or rogue CA issuing a fraudulent certificate for your domain. Some mobile banking apps and payment SDKs use pinning for their backend connections.
Pinning is hard to maintain
Certificate pinning breaks every time you rotate your certificate if you pin the leaf cert instead of the public key. Pin the public key (SPKI hash), not the certificate. Build a rotation plan before enabling pinning in production.Quantum vulnerability in TLS
The quantum threat in TLS is specifically in the key exchange step. ECDHE (used in TLS 1.3) is broken by Shor's algorithm running on a sufficiently large quantum computer. This means:
- A quantum adversary could break the session key and decrypt recorded traffic.
- An adversary recording TLS sessions today could decrypt them in 2030+ when quantum computers exist (Harvest Now, Decrypt Later).
- The symmetric cipher (AES-256-GCM) is not broken. Only the key exchange is vulnerable.
The migration path is hybrid TLS: combining X25519 (classical ECDHE) with ML-KEM-768 (post-quantum key encapsulation). Chrome and Cloudflare already support this. The handshake remains backward-compatible with servers that do not support PQC.
Forward secrecy does not protect against quantum
Forward secrecy prevents a future compromise of the server's private key from exposing past sessions. But it does not help against an adversary who records the full TLS handshake and later uses a quantum computer to break the ECDHE key exchange itself.