Skip to main content

Encryption in Transit

Secure data with TLS and mutual authentication

TL;DR​

TLS (Transport Layer Security) encrypts data in transit. HTTPS is HTTP over TLS. mTLS (Mutual TLS) requires both client and server to authenticate via certificates. Use TLS 1.3+ with strong cipher suites. Enforce HTTPS on all connections. Use mTLS for service-to-service communication (microservices). Certificates from trusted CAs, rotated before expiry.

Learning Objectives​

  • Understand TLS handshake and encryption
  • Implement HTTPS for web applications
  • Use mTLS for microservice authentication
  • Choose appropriate cipher suites
  • Manage certificate lifecycles

Motivating Scenario​

Problem: API sends API keys over HTTP. Attacker on the same WiFi network intercepts traffic, steals keys. Mobile app sends user data unencrypted; ISP logs it. Microservices talk over plain HTTP; internal attacker intercepts service-to-service communication.

Solution: HTTPS (TLS) encrypts all web traffic. Attacker sees ciphertext, not keys. Microservices use mTLS; each service has certificate; mutual authentication prevents internal impersonation.

Core Concepts​

TLS Handshake​

Client                              Server
  |--- ClientHello (ciphers) ------>|
  |<-- ServerHello (cert, cipher) --|
  |<-- ServerKeyExchange ------------|
  |--- ClientKeyExchange ----------->|
  |--- Finished (encrypted) -------->|
  |<-- Finished (encrypted) --------|
  |====== Encrypted channel ========|
  1. ClientHello: Client offers cipher suites and TLS versions
  2. ServerHello: Server selects cipher suite, sends certificate
  3. Key Exchange: Both derive shared secret (symmetric key)
  4. Finished: Both encrypt "Finished" message to verify handshake integrity
  5. Data Transfer: All data encrypted with symmetric key

TLS vs mTLS​

TLS (One-way authentication)
  1. Server has certificate, proves identity
  2. Client verifies server certificate
  3. Client doesn't authenticate
  4. Example: HTTPS, bank websites
  5. Good for client-to-server (web)
mTLS (Mutual authentication)
  1. Server has certificate, proves identity
  2. Client has certificate, proves identity
  3. Both verify each other
  4. Requires cert management for all clients
  5. Good for service-to-service (microservices)

Cipher Suites​

A cipher suite combines:

  • Key Exchange (ECDHE): Generate shared secret
  • Authentication (ECDSA): Verify certificates
  • Encryption (AES-256): Encrypt data
  • MAC (SHA-256): Verify data integrity
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
       ↑                ↑              ↑
     Key Exchange    Encryption      MAC

Strong (2025):

  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_256_GCM_SHA384

Weak (deprecated, don't use):

  • TLS_RSA_WITH_AES_128_CBC_SHA (no forward secrecy)
  • Any NULL cipher

Practical Examples​

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('private-key.pem'),
  cert: fs.readFileSync('certificate.pem')
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end('Encrypted connection');
}).listen(443);

When to Use / When Not to Use​

Use TLS When
  1. All HTTP connections (HTTPS standard)
  2. Transmitting sensitive data
  3. Any network communication
  4. APIs, databases, message queues
  5. Regulatory compliance (HIPAA, PCI)
Use mTLS When
  1. Service-to-service communication
  2. Microservices architectures
  3. Zero trust networks
  4. High-security internal networks
  5. Certificate infrastructure available

Advanced Security Patterns​

Certificate Pinning for Mobile Apps​

Prevent MITM even if CA is compromised.

// iOS: Pin certificate in app
import Alamofire

let pinnedCertificates = [
    "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
]

let evaluators: [String: ServerTrustEvaluating] = [
    "api.example.com": CertificatePinningEvaluator(pinnedCertificates: pinnedCertificates)
]

let serverTrustManager = ServerTrustManager(evaluators: evaluators)
let session = Session(serverTrustManager: serverTrustManager)

Certificate Transparency (CT) Logging​

Public log of all issued certificates. Detect rogue certs.

# Check if certificate is in CT logs
openssl x509 -in cert.pem -text | grep CT

# Requires: SCT (Signed Certificate Timestamp) in certificate

Perfect Forward Secrecy (PFS)​

Old recorded traffic can't be decrypted if key is compromised (ephemeral keys).

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
                  ↑ ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
                    = New key per session, not reused

If RSA key is stolen, PFS ensures past sessions remain secure (attacker can't decrypt them).

Zero-Downtime Certificate Rotation​

Rotate certificates without downtime.

# 1. Generate new certificate
openssl req -new -key service-key.pem -out service.csr
openssl x509 -req -in service.csr -CA ca-cert.pem -CAkey ca-key.pem \
  -out service-new-cert.pem -days 365

# 2. Deploy new cert alongside old one
# Nginx can have multiple certificates:
ssl_certificate /etc/ssl/certs/service-cert-old.pem;
ssl_certificate /etc/ssl/certs/service-cert-new.pem;

# 3. Wait for all clients to have new cert (DNS TTL + grace period)
# 4. Remove old certificate

# For Kubernetes, update secret without pod restart:
kubectl create secret tls service-tls --cert=service-new-cert.pem --key=service-key.pem
kubectl set env deployment/service CERT_RELOAD=true  # If app watches secret

Patterns and Pitfalls​

Pitfall: Self-signed certificates (easy, but risky). Attacker can forge one. Use trusted CAs (Let's Encrypt free).

Pattern: HSTS header (Strict-Transport-Security). Tells browser: always HTTPS. Prevents downgrade attacks.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Pitfall: Weak cipher suites. Old servers use RC4, DES. Use only TLS 1.3 and strong ciphers.

Pattern: Certificate pinning for mobile apps. App only trusts specific certificate. Prevents MITM even if CA compromised.

Pitfall: Certificate expiry. Service stops accepting connections. Monitor expiry dates; auto-renew via Let's Encrypt.

# Monitor certificate expiry
openssl x509 -in cert.pem -noout -dates

# Alert if expiry under 30 days

Pattern: Separate keys per environment. Prod key never used for dev. If key compromised, only one environment affected.

Pitfall: Logging TLS keys (SSLKEYLOGFILE). Enables MITM if log is exposed. Keep keys confidential.

Design Review Checklist​

  • HTTPS enforced for all web connections
  • TLS 1.3 or TLS 1.2 (no older versions)
  • Strong cipher suites configured
  • Certificates from trusted CAs
  • Certificate rotation automated (Let's Encrypt or similar)
  • HSTS header enabled
  • Downgrade attacks prevented (redirect HTTP to HTTPS)
  • mTLS for internal service-to-service communication
  • Certificate pinning for mobile apps (optional)
  • No self-signed certificates in production
  • Regular security audits (SSL Labs test)

Self-Check​

  • What happens in the TLS handshake?
  • Why is mTLS important for microservices?
  • How would you handle certificate rotation without downtime?
One Takeaway

TLS + mTLS = encrypted, authenticated communication that prevents eavesdropping and impersonation.

Next Steps​

  • Read Key Management for certificate lifecycle
  • Study Network Security for defense in depth
  • Explore Compliance Frameworks for regulatory requirements

References​

  • RFC 8446: TLS 1.3
  • Mozilla SSL Configuration Generator
  • OWASP Transport Layer Protection Cheat Sheet
  • Let's Encrypt (Free TLS certificates)