How HTTPS protects your data
The padlock in the address bar stands for TLS — a handshake that agrees secret keys, proves the server’s identity with certificates, and then protects every byte. Step through a real TLS 1.3 handshake and learn what can still go wrong.
In this lecture you will
- Describe the three guarantees TLS provides — confidentiality, integrity and authentication
- Step through a TLS 1.3 handshake and explain each message
- Explain how certificates and certificate authorities establish trust
- Recognize common TLS failures and misconfigurations in operations
HTTPS is simply HTTP carried inside TLS — Transport Layer Security. TLS sits between TCP and the application and quietly provides three guarantees that the open internet cannot:
- Confidentiality
- Nobody on the network path — Wi-Fi owner, ISP, anyone — can read the traffic.
- Integrity
- Any change to the data in transit is detected and the connection fails.
- Authentication
- The client can verify it is talking to the genuine server for that domain, not an impostor.
It does this with exactly the tools from the last lecture: a key exchange, symmetric encryption and digital signatures.
The TLS 1.3 handshake
Before any HTTP data flows, client and server run a short handshake. TLS 1.3, the current version, needs just one round trip. Scroll through it:
- 1ClientHello
The browser lists the TLS versions and cipher suites it supports, sends its half of an ephemeral key exchange, and names the site it wants (SNI), so one server can host many domains.
- 2ServerHello
The server picks the cipher suite and sends its half of the key exchange. Each side now combines its secret with the other’s public value to compute the same shared secret — which never crossed the network.
- 3Encrypted from here
Everything else is already encrypted: the server sends its certificate chain, a CertificateVerify signature proving it holds the certificate’s private key, and a Finished message covering the whole handshake.
- 4Check the certificate
The browser verifies the chain up to a root authority it already trusts, and that the certificate names this domain, hasn’t expired and hasn’t been revoked. Any failure stops the connection.
- 5Client Finished and the request
The browser sends its own Finished message and — in the same flight — the encrypted HTTP request. One round trip after the first message, data is flowing.
- 6Protected data
Requests and responses travel encrypted and integrity-protected with the session keys. Each record carries an authentication tag, so tampering is detected.
Certificates and trust
A certificate binds a domain name to a public key, and is signed by a certificate authority (CA). Your operating system or browser ships with a list of trusted root CAs. Sites usually present a chain: their own certificate, signed by an intermediate CA, signed by a root. The browser checks every signature up to a trusted root.
Try the common ways this goes wrong, and the error each one produces:
Error codes are Chrome’s; other browsers show equivalents. Almost every certificate outage is an expired certificate or an incomplete chain — both preventable with automated renewal and a check from a non-browser client such as curl.
Because the key exchange uses fresh, ephemeral keys for each session, TLS 1.3 provides forward secrecy: even if the server’s long-term private key is stolen later, recorded past sessions can’t be decrypted.
What HTTPS does not do
- It doesn’t make a site trustworthy — phishing sites have valid certificates too. The padlock means private and authentic connection to this domain, not safe business.
- It doesn’t protect data once it arrives: a vulnerable application or database can still leak it.
- It doesn’t hide which site you visit from your network provider — the domain name is visible in DNS and in the SNI field, although newer extensions are starting to encrypt it.
Put yourself in the shoes of someone running the café Wi-Fi, watching a customer log in:
HTTPS hides what you send and which pages you visit on a site, but not which server you talk to or how much data flows. Encrypted DNS (DNS over HTTPS) and Encrypted Client Hello hide the domain name as well, where both the browser and the site support them. Addresses and values are examples.
Operating TLS without outages
- Automate renewal
- Use ACME (for example Let’s Encrypt) or your cloud’s managed certificates so certificates renew themselves. Monitor expiry dates anyway.
- Serve the full chain
- Include the intermediate certificate. Some clients fail when it is missing, even if browsers cope.
- Modern settings
- Enable TLS 1.2 and 1.3 only, with modern cipher suites. Disable older protocol versions.
- HSTS
- The Strict-Transport-Security header tells browsers to always use HTTPS for your domain, preventing downgrade tricks.
TLS protects data on its way to your servers. In the last lecture of this module, we protect the most sensitive data many systems hold: users’ passwords.
Key takeaways
- TLS encrypts traffic, detects tampering and proves the server’s identity.
- In TLS 1.3, one round trip agrees fresh session keys through an ephemeral key exchange, giving forward secrecy.
- Certificates bind a domain name to a public key and are signed by certificate authorities the browser already trusts.
- Expired certificates, missing intermediates and name mismatches are among the most common production outages.
Check your understanding
3 questions · answers explainedQ1How does the browser know it is really talking to shop.example.com and not an impostor?
Q2What does forward secrecy protect against?
Q3Users suddenly see “Your connection is not private” on your API’s domain at midnight. What is the most likely cause?