Software Engineer's Notes

What is Secure Socket Layer (SSL)?

Secure Socket Layer (SSL) is a cryptographic protocol originally designed to secure communication over networks. Modern “SSL” in practice means TLS (Transport Layer Security)—the standardized, more secure successor to SSL. Although people say “SSL certificate,” what you deploy today is TLS (prefer TLS 1.2+, ideally TLS 1.3).

Goal: ensure that data sent between a client (browser/app) and a server is confidential, authentic, and untampered.

How SSL/TLS Works (Step by Step)

1. Client Hello
   The client initiates a connection, sending supported TLS versions, cipher suites, and a random value.
2. Server Hello & Certificate
   The server picks the best mutual cipher suite, returns its certificate chain (proving its identity), and sends its own random value.
3. Key Agreement
   Using Diffie–Hellman (typically ECDHE), client and server derive a shared session key. This provides forward secrecy (a future key leak won’t decrypt past traffic).
4. Certificate Validation (Client-side)
   The client verifies the server’s certificate:
   • Issued by a trusted Certificate Authority (CA)
   • Hostname matches the certificate’s CN/SAN
   • Certificate is valid (not expired/revoked)
5. Finished Messages
   Both sides confirm handshake integrity. From now on, application data is encrypted with the session keys.
6. Secure Data Transfer
   Data is encrypted (confidentiality), MAC’d or AEAD-authenticated (integrity), and tied to the server identity (authentication).

Key Features & Components (In Detail)

1) Certificates & Public Key Infrastructure (PKI)

• End-Entity Certificate (the “SSL certificate”): issued to your domain/service.
• Chain of Trust: your cert → intermediate CA(s) → root CA (embedded in OS/browser trust stores).
• SAN (Subject Alternative Name): lists all domain names the certificate covers.
• Wildcard Certs: e.g., *.example.com—useful for many subdomains.
• EV/OV/DV: validation levels; DV is common and free via Let’s Encrypt.

2) TLS Versions & Cipher Suites

• Prefer TLS 1.3 (simpler, faster, more secure defaults).
• Cipher suites define algorithms for key exchange, encryption, and authentication.
• Favor AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305).

3) Perfect Forward Secrecy (PFS)

• Achieved via (EC)DHE key exchange. Protects past sessions even if the server key is compromised later.

4) Authentication Models

• Server Auth (typical web browsing).
• Mutual TLS (mTLS) for APIs/microservices: both client and server present certificates.

5) Session Resumption

• TLS session tickets or session IDs speed up repeat connections and reduce handshake overhead.

6) Integrity & Replay Protection

• Each record has an integrity check (AEAD tag). Sequence numbers and nonces prevent replays.

Benefits & Advantages

• Confidentiality: prevents eavesdropping (e.g., passwords, tokens, PII).
• Integrity: detects tampering and man-in-the-middle (MITM) attacks.
• Authentication: clients know they’re talking to the real server.
• Compliance: many standards (PCI DSS, HIPAA, GDPR) expect encryption in transit.
• SEO & Browser UX: HTTPS is a ranking signal; modern browsers label HTTP as “Not Secure.”
• Performance: TLS 1.3 plus HTTP/2 or HTTP/3 (QUIC) can be faster than legacy HTTP due to fewer round trips and better multiplexing.

When & How Should We Use It?

Short answer: Always use HTTPS for public websites and TLS for all internal services and APIs—including development and staging—unless there’s a compelling, temporary reason not to.

Use cases:

• Public web apps and websites (user logins, checkout, dashboards)
• REST/gRPC APIs between services (often with mTLS)
• Mobile apps calling backends
• Messaging systems (MQTT over TLS for IoT)
• Email in transit (SMTP with STARTTLS, IMAP/POP3 over TLS)
• Data pipelines (Kafka, Postgres/MySQL connections over TLS)

Real-World Examples

1. E-commerce Checkout
   • Browser ↔ Storefront: HTTPS with TLS 1.3
   • Storefront ↔ Payment Gateway: TLS with pinned CA or mTLS
   • Benefits: protects cardholder data; meets PCI DSS; builds user trust.
2. B2B API Integration
   • Partner systems exchange JSON over HTTPS with mTLS.
   • Mutual auth plus scopes/claims reduces risk of credential leakage and MITM.
3. Service Mesh in Kubernetes
   • Sidecars (e.g., Envoy) automatically enforce mTLS between pods.
   • Central policy defines minimum TLS version/ciphers; cert rotation is automatic.
4. IoT Telemetry
   • Device ↔ Broker: MQTT over TLS with client certs.
   • Even if devices live on hostile networks, data remains confidential and authenticated.
5. Email Security
   • SMTP with STARTTLS opportunistic encryption; for stricter guarantees, use MTA-STS and TLSRPT policies.

Integrating TLS Into Your Software Development Process

Phase 1 — Foundation & Inventory

• Asset Inventory: list all domains, subdomains, services, and ports that accept connections.
• Threat Modeling: identify data sensitivity and where mTLS is required.

Phase 2 — Certificates & Automation

• Issue Certificates: Use a reputable CA. For web domains, Let’s Encrypt via ACME (e.g., Certbot) is ideal for automation.
• Automated Renewal: never let certs expire. Integrate renewal hooks and monitoring.
• Key Management: generate keys on the server or HSM; restrict file permissions; back up securely.

Phase 3 — Server Configuration (Web/App/API)

• Enforce TLS: redirect HTTP→HTTPS; enable HSTS (with preload once you’re confident).
• TLS Versions: enable TLS 1.2+, prefer TLS 1.3; disable SSLv2/3, TLS 1.0/1.1.
• Ciphers: choose modern AEAD ciphers; disable weak/legacy ones.
• OCSP Stapling: improve revocation checking performance.
• HTTP/2 or HTTP/3: enable for multiplexing performance benefits.

Phase 4 — Client & API Hardening

• Certificate Validation: ensure hostname verification and full chain validation.
• mTLS (where needed): issue client certs; manage lifecycle (provision, rotate, revoke).
• Pinning (cautious): consider HPKP alternatives (TLSA/DANE in DNSSEC or CA pinning in apps) to avoid bricking clients.

Phase 5 — CI/CD & Testing

• Automated Scans: add TLS configuration checks (e.g., linting scripts) in CI.
• Integration Tests: verify HTTPS endpoints, expected protocols/ciphers, and mTLS paths.
• Dynamic Tests: run handshake checks in staging before prod deploys.

Phase 6 — Monitoring & Governance

• Observability: track handshake errors, protocol use, cert expiry, ticket keys.
• Logging: log TLS version and cipher used (sans secrets).
• Policy: minimum TLS version, allowed CAs, rotation intervals, and incident runbooks.

Practical Snippets & Commands

Generate a Private Key & CSR (OpenSSL)

# 1) Private key (ECDSA P-256)
openssl ecparam -genkey -name prime256v1 -noout -out privkey.pem

# 2) Certificate Signing Request (CSR)
openssl req -new -key privkey.pem -out domain.csr -subj "/CN=example.com"

Use Let’s Encrypt (Certbot) – Typical Webserver

# Install certbot per your OS, then:
sudo certbot --nginx -d example.com -d www.example.com
# or for Apache:
sudo certbot --apache -d example.com

cURL: Verify TLS & Show Handshake Details

curl -Iv https://example.com

Java (OkHttp) with TLS (hostname verification is on by default)

OkHttpClient client = new OkHttpClient.Builder().build();
Request req = new Request.Builder().url("https://api.example.com").build();
Response res = client.newCall(req).execute();

Python (requests) with Certificate Verification

import requests
r = requests.get("https://api.example.com", timeout=10)  # verifies by default
print(r.status_code)

Enforcing HTTPS in Nginx (Basic)

server {
listen 80;
server_name example.com http://www.example.com;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
server_name example.com http://www.example.com;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;

# Provide full chain and key
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# HSTS (enable after testing redirects)
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” always;

location / {
proxy_pass http://app:8080;
}
}

Common Pitfalls (and How to Avoid Them)

• Forgetting renewals: automate via ACME; alert on expiry ≥30 days out.
• Serving incomplete chains: always deploy the full chain (leaf + intermediates).
• Weak ciphers/old protocols: disable TLS 1.0/1.1 and legacy ciphers.
• No HSTS after go-live: once redirects are stable, enable HSTS (careful with preload).
• Skipping internal encryption: internal traffic is valuable to attackers—use mTLS.
• Certificate sprawl: track ownership and expiry across teams and environments.

FAQ

Is SSL different from TLS?
Yes. SSL is the older protocol. Today, we use TLS; the term “SSL certificate” persists out of habit.

Which TLS version should I use?
TLS 1.3 preferred; keep TLS 1.2 for compatibility. Disable older versions.

Do I need a paid certificate?
Not usually. DV certs via Let’s Encrypt are trusted and free. For enterprise identity needs, OV/EV may be required by policy.

When should I use mTLS?
For service-to-service trust, partner APIs, and environments where client identity must be cryptographically proven.

Developer Checklist (Revision List)

• Inventory all domains/services needing TLS
• Decide: public DV vs internal PKI; mTLS where needed
• Automate issuance/renewal (ACME) and monitor expiry
• Enforce HTTPS, redirects, and HSTS
• Enable TLS 1.3 (keep 1.2), disable legacy protocols
• Choose modern AEAD ciphers (AES-GCM/ChaCha20-Poly1305)
• Configure OCSP stapling and session resumption
• Add TLS tests to CI/CD; pre-prod handshake checks
• Log TLS version/cipher; alert on handshake errors
• Document policy (min version, CAs, rotation, mTLS rules)