TLS/SSL Security

TLS 1.2 vs. TLS 1.3: The Architectural Shift

For senior engineers, understanding the move from TLS 1.2 to 1.3 is critical for optimizing latency and security. TLS 1.3 (RFC 8446) is not just an update; it's a rewrite.

• Handshake Latency: TLS 1.2 requires 2-RTT (Round Trip Times) before the actual data flows. TLS 1.3 reduces this to 1-RTT by guessing the key exchange protocol (usually ECDHE). It also supports 0-RTT (Zero Round Trip Time) Resumption, allowing clients to send data immediately to known servers, though this introduces replay attack risks.
• Security Hardening: TLS 1.3 removed obsolete algorithms like RSA key exchange (which lacks Forward Secrecy), RC4, SHA-1, and CBC mode ciphers. All TLS 1.3 ciphers use AEAD (Authenticated Encryption with Associated Data).

Certificate Chain Validation

A common production outage cause is the 'incomplete certificate chain'. Browsers often cache intermediate certificates, masking configuration errors that crash server-to-server API calls.

Use OpenSSL to diagnose the full chain sent by a server:

Cipher Suites and Forward Secrecy

Forward Secrecy (FS) ensures that if the server's private key is compromised today, past sessions remains secure. This requires ephemeral key exchange (DHE or ECDHE).

Nginx Hardening Configuration:

Mutual TLS (mTLS)

In a Zero Trust architecture, relying on IP whitelisting is insufficient. mTLS requires both the client and server to present a certificate. This is the standard for service mesh (e.g., Istio, Linkerd) communication.

To test mTLS with curl, you must provide the client's public cert and private key: