TLS Under the Hood

TLS is where this chapter's pieces come together: key exchange, symmetric encryption, and certificates cooperating to give the padlock its meaning. Understanding the handshake — how a client and app.meridian.example agree on a cipher, verify identity, and derive session keys — is what lets a defender reason about misconfigurations, downgrade attacks, and what the padlock does and does not promise.

This topic opens the black box the beginner course drew as a padlock, so that the TLS settings you will harden across the rest of the book are settings you actually understand.

The Handshake, Step by Step

In a modern TLS 1.3 handshake the client sends a hello offering cipher suites and its key-exchange material; the server responds with its certificate and its own key material; both sides derive the same session keys from the exchange; and application data flows encrypted. TLS 1.3 streamlines this to a single round trip and drops the legacy weak options that made earlier versions negotiable down to insecurity.

Authentication vs Encryption in TLS

The certificate authenticates the server — is this really app.meridian.example? — while the key exchange establishes confidentiality. These are separate jobs, and conflating them is the root of the padlock misunderstanding: a valid padlock means "encrypted to the site this certificate names," not "this site is safe." A phishing site can hold a perfectly valid certificate for its own look-alike name.

Cipher Suites and Versions

A cipher suite bundles the choices — key exchange, authentication, bulk encryption, and integrity. TLS 1.2 with ECDHE and AES-GCM is the acceptable floor; TLS 1.3 is the target; and SSLv3, TLS 1.0, and TLS 1.1 are dead and must be disabled. Leaving old versions enabled "for compatibility" creates a downgrade path an attacker can force, which is why the version and cipher policy is a security setting, not a performance one.

# scan the endpoint's protocols, ciphers, and certificate for weak settings
testssl.sh app.meridian.example:443

# or, quickly, see what a single connection negotiates:
openssl s_client -connect app.meridian.example:443 -tls1_2 </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher'

# flag: any handshake that still succeeds on TLS 1.0/1.1 or a non-forward-secret cipher

A scanner walks every protocol version and cipher the endpoint will accept and flags the weak ones — an enabled TLS 1.0, a cipher without forward secrecy, an expiring certificate. The single connection form shows what one client actually negotiated. Either way, the finding you act on is the same: any legacy protocol or weak suite still accepted is a downgrade path to close.

Downgrade and Stripping Attacks

An attacker who can force a weaker version, or strip TLS entirely by keeping the user on plain HTTP, defeats all of it. The defenses are enforcing a modern minimum version and HSTS — a header that tells browsers to only ever use HTTPS for the site, so the first request cannot be downgraded. This is why "redirect HTTP to HTTPS" is necessary but not sufficient on its own.