Security
Advanced 19 min read Security

Network Security & TLS

Secure the wire: TLS certificates and the handshake, forward secrecy, trust chains, DNS hardening and network segmentation. Understand how encryption actually protects data in transit — and where it does not.

TLSHTTPScertificatesCAhandshakeforward secrecySNIDNSsegmentation
Prerequisites: Security Fundamentals TCP/IP DNS
Introduction

What is this?

Network security protects data in transit and limits who can reach what. TLS (Transport Layer Security) is the encryption protocol behind HTTPS, providing confidentiality, integrity and authentication of the server. It relies on a chain of trust from certificate authorities (CAs) down to leaf certificates for your hostname.

Motivation

Why do you need it?

  • Data in transit is the one place every service is exposed — anyone on the wire or at the load balancer can sniff plaintext.
  • TLS authenticates the server, preventing man-in-the-middle impersonation of your hostname.
  • Forward secrecy means even a stolen private key cannot decrypt past traffic.
  • DNS is the backbone of modern infrastructure; cache poisoning or hijacked resolution is a total compromise.
  • Segmentation and least-access networking limit lateral movement when one service is breached.
Think about it

Mental model

Imagine

A sealed, tamper-evident envelope

Think of

A TLS session

The envelope hides the contents (encryption), proves the seal was not broken (integrity), and is addressed to a verified recipient (authentication). Forward secrecy means the envelope is destroyed after delivery.

Mechanics

How it works

  • The client and server negotiate a TLS version and cipher suite during the handshake.
  • The server presents its certificate chain; the client validates each signature up to a trusted root CA.
  • Ephemeral key exchange (ECDHE) creates session keys that are destroyed after the session — forward secrecy.
  • All application data is encrypted under the session keys with message authentication codes for integrity.
  • Certificate expiry, hostname mismatch and untrusted roots cause validation failures that clients reject.

A TLS 1.3 handshake at a glance.

ClientHello
ServerHello
Certificate chain
Key exchange
Encrypted app data
Reference

Key commands

curl -vI https://example.com 2>&1 | grep -i 'SSL connection'

Show which TLS version and cipher were negotiated.

openssl s_client -connect example.com:443 -servername example.com

Run a raw TLS handshake and print the certificate chain and verification code.

curl --tls-max 1.2 -sI https://example.com

Force the client to cap the TLS version to detect server compatibility.

dig example.com +short

Resolve a hostname to its A records quickly.

curl --cert-status -sI https://example.com

Request OCSP stapling status for real-time revocation information.

Hands-on

Examples

Probe a TLS endpoint by hand

Probe a TLS endpoint by hand
curl -v https://example.com 2>&1 | grep -iE "SSL connection|subject:|issuer:"
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "subject=|issuer=|Verify return code"
dig example.com +short
nslookup example.com

curl shows the negotiated TLS version and the certificate's subject and issuer. openssl s_client performs a raw handshake and reports the verification code. dig and nslookup confirm the DNS records the connection will use.

Real world

In production

  • All traffic is HTTPS with TLS 1.2+ (ideally 1.3) and HSTS enforced at the load balancer.
  • Certificates are issued by Let's Encrypt or a private PKI and renewed automatically well before expiry.
  • mTLS secures service-to-service calls inside the mesh, with per-workload certificates rotated on a schedule.
  • DNS is monitored for anomalies and protected against cache poisoning; resolvers and zones are hardened.
  • Network segmentation (VPCs, security groups, service meshes) enforces least-access between tiers.
Guidelines

Best practices

  • Enforce a minimum TLS version (1.2) and prefer modern ciphers; disable deprecated suites.
  • Pin leaf certificates via public-key pinning or TLS-ALPN, never hardcode short-lived CAs.
  • Use OCSP stapling or short-lived certificates instead of blocking on revocation checks.
  • Keep private keys on hardware or KMS-backed storage and rotate them on a schedule.
  • Apply DNSSEC, restrict recursive resolvers, and separate public from private zones.
Watch out

Common mistakes

  • Shipping services with self-signed certificates that browsers and clients reject.
  • Allowing TLS 1.0/1.1 or weak ciphers for legacy clients, exposing traffic to downgrade attacks.
  • Ignoring certificate expiry until the outage — automation should watch every cert.
  • Storing private keys in the repo or image next to the public certificate.
  • Treating the load balancer TLS termination as enough while internal links stay plaintext.
Root cause analysis

Common issues

Error
Self-signed certificate in certificate chain
Root cause

The server presents a leaf not signed by any trusted root

Fix

Install the CA-signed certificate chain, or add the private CA to the client trust store.

Error
Hostname does not match the certificate
Root cause

The certificate's SANs do not include the requested hostname

Fix

Issue a certificate covering the exact hostname, or point the client at the correct name.

Error
SSL connection refused / TLS version not supported
Root cause

The client offers only an older protocol the server rejects

Fix

Upgrade the client to TLS 1.2+, or temporarily enable an allowed legacy profile for migration.

When things break

Debugging tips

  • Use openssl s_client to see the exact handshake failure reason (untrusted root, expired, hostname mismatch).
  • Compare the Subject Alternative Names against the URL you requested — mismatch is the classic TLS error.
  • Check the server's TLS configuration with a TLS checker against your public endpoints.
  • Verify DNS first with dig: a wrong A/AAAA record produces a certificate mismatch that is not a TLS bug.
Interviews

Interview checkpoint

Practice

Hands-on lab

TLS Handshake Deep Dive
30 min · advanced
In progress
Objectives
  • Resolve a host and confirm DNS records
  • Inspect the negotiated TLS version and cipher
  • Read certificate subject, issuer and chain
  • Observe validation failures with bad certificates

TLS Handshake Deep Dive

30 min · advanced

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

What does the client validate when it receives the server's certificate chain?

2

Forward secrecy protects past sessions even if the server's private key is later stolen.

3

Which TLS version mandates ephemeral key exchange for every session?

Quick reference

Cheat sheet

Inspect endpoints
openssl s_client -connect host:443Raw handshake + chain
curl -vI https://hostNegotiated version and cipher
curl --tls-max 1.2 -sICap the TLS version
dig host +shortResolve DNS records
Policies
TLS 1.2 minimumReject older protocols
HSTSForce HTTPS for clients
mTLSMutual authentication between services
DNSSECAuthenticate DNS responses
Go deeper

Official documentation

RFC 8446 — TLS 1.3
rfc
RFC 5280 — X.509 Certificates
rfc
RFC 6066 — SNI
rfc
Let's Encrypt: How It Works
docs
Mozilla SSL Configuration Generator
docs