tls

The classic 'what happens when you type google.com' turned into a security question. Interviewers want the stack in order, with the attacker who sits at each layer and the control that removes them.

Encryption alone does not stop a man in the middle: you could be encrypting to the attacker. The property that matters is authentication, and every successful MITM is a story about how it was skipped.

Users type a domain, not https://. That one habit gave attackers a plain-HTTP first request to hijack. HSTS closes it, and preloading closes it before the first visit, with a commitment you cannot easily undo.

Every TLS error is a specific check failing. Engineers who can name which check, from the chain the client actually saw, fix outages in minutes and never 'fix' them by turning validation off.

Inspection is a man in the middle the organisation chose. Interviewers want the mechanism, then a clear view of the new single point of failure it creates and the traffic it must never touch.

Pinning trades availability for a narrower trust set. The answer that scores compares each pin target by what it survives, and uses HPKP's retirement as evidence of what goes wrong.

Message names are table stakes. The interviewer is listening for why CertificateVerify exists and what Finished actually checks.

Checking the signature is one step of seven. The bugs that matter live in the other six, and in code that switches validation off.

The question behind the question: if your server's private key leaks next year, what happens to the traffic someone recorded today?

Any trusted CA can issue a certificate for your domain. The scored answer explains how public logs make that visible and how to turn the logs into an alert.

Encryption hides content, not length. The scored answer shows how compression turns length into a leak when secrets and attacker text share a message, and where that bites today.

Data encrypted today can be recorded and decrypted when a capable quantum computer exists. The scored answer prioritises by how long data must stay secret, starts with key exchange, and builds crypto agility.

TLS protects bytes on the wire between two endpoints. The scored answer lists what lies outside that boundary, so nobody mistakes 'we use HTTPS' for a security design.

Being able to switch algorithms is essential. Letting an attacker choose which algorithm you switch to is a vulnerability with a long history.

Most candidates can recite TLS 1.3. Interviewers ask for 1.2 because it is still everywhere, and because every change in 1.3 is the fix for an attack on 1.2.

A certificate is a signed statement with a short list of claims: this key, these names, these uses, this period, issued by this CA. Every validation failure you have seen is one of those claims not holding.

There is no single list of trusted roots. Browsers, operating systems, language runtimes and container images each carry their own, updated on their own schedules, and production outages follow from the differences.

OpenSSL is two libraries and a command-line tool. Most TLS failures blamed on it are applications that never asked it to check the hostname, or told it to stop checking at all.

Pinning narrows trust, and every outage story about it is a rotation story. The scored answer decides whether to pin at all, pins public keys with backups, and plans for the release that can never update.

Two different questions hide here: does the app validate TLS at all, and does it pin? Testers who merge them either miss the critical bug or report a non-issue as one.

Pinning protects the user from the network. It was never going to protect your API from the person holding the phone, and the good answer explains both halves.

Both platforms let an app declare its transport rules in a file the reviewer can read in seconds. Knowing which lines are dangerous makes you fast in a mobile review.