ComputeSphereLearn
Console
Learning paths / Cloud foundations / TLS and certificates

What HTTPS protects, and what it doesn't

Reading · 5 min · Module 7, lesson 1 of 420 min left in this module

Module 7 · TLS and certificatesLesson 1 of 4

Goal: Say what TLS keeps private and proves on an HTTPS connection, and what it leaves visible or unprotected.

3:58 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know the three jobs HTTPS does for every request. And what it still leaves in plain view.

[00:09] Plain HTTP

Our request has now reached TLS. Without it, HTTP travels as readable text. Anyone on the path can read it. The café Wi-Fi, your internet provider, or a compromised router. And change it, too.

[00:24] Three jobs

HTTPS is HTTP, sent inside a TLS connection. And TLS does three jobs. First, it keeps the request and the response private. Second, it detects tampering. Change one byte on the way, and the other side drops the connection. Third, it proves you reached a server that holds a certificate for the name you asked for.

[00:50] The handshake

All of that is set up by a handshake, before the first byte of HTTP is sent. The browser says hello. It names the site it wants, and sends its half of a key exchange. The server answers with its half. From the two, both sides compute the same secret keys. Nobody watching can. Next, the server sends its certificate, and proves it holds the key that goes with it. The browser checks three things. The name matches. The dates are valid. And it leads to an authority it trusts. Then both sides say finished, and the request goes out, encrypted. It all takes one round trip, on port four four three.

[01:33] See it for real

Point curl at a deployed service, and ask for verbose output. First come the hellos, then the certificate, then finished. Its name covers this address, and a trusted authority issued it. Only after that does the GET request go out.

[01:52] What it protects

Once the handshake is done, everything inside the connection is encrypted. The path, and the query string. Every header, including cookies and authorization tokens. And the body. Form fields, passwords, JSON, and files. That's why logins, API keys, and session cookies should only ever travel over HTTPS.

[02:16] What it doesn't protect

But HTTPS doesn't hide everything. First, it doesn't hide which site you visit. The DNS lookup, the server's IP address, and usually the name in the browser's hello are all visible. The page you open on that site isn't. A newer extension, Encrypted Client Hello, can hide that name, where both sides support it.

[02:41] The padlock and the ends

Second, it doesn't tell you whether a site is honest. A certificate proves who controls a name. Not that they're trustworthy. Phishing sites get valid certificates too.

And third, data at either end. TLS only covers the trip. Once your data arrives, keeping it safe is the server's job. And on your device, malware sees what you see.

[03:08] On ComputeSphere

On ComputeSphere, every web service gets an HTTPS address, with a valid certificate, from its first deploy. When you add your own domain, ComputeSphere gets its certificate for you, and renews it.

[03:22] Recap

So, a quick recap. TLS keeps what you send private, catches tampering, and proves the server holds the name. It doesn't hide which site you visit. And a padlock proves the name. Not that the site is honest.

Here's a question to check yourself. You log in to a shop over café Wi-Fi. What can the network see? That you connected to the shop. Not your password, or anything you sent. Next, you'll see who vouches for certificates. I'll see you in the next lesson.

TLS at a glance

Encryption
Keeps traffic private and untampered.
Handshake
Agrees keys in one round trip.
Certificate
Proves which names the server holds.
Certificate authority
Vouches for certificates your device trusts.
Four parts make HTTPS work.

Key idea

HTTPS is HTTP sent inside a TLS connection. TLS does three jobs: it keeps the request and response private, detects any tampering on the way, and proves you reached a server that holds a certificate for the name you asked for.

Plain HTTP travels as readable text. Anyone on the path, such as the café Wi-Fi, your internet provider or a compromised router, can read it and change it. TLS closes that gap before the first HTTP byte is sent.

How the connection starts

How HTTPS starts: the TLS handshake

Browser
app.example.com
1Hello: app.example.com, TLS 1.3, my key share
  1. 1Browser app.example.com Hello: app.example.com, TLS 1.3, my key share

Step 1 of 5

The browser names the site it wants (so one server can host many names), lists the TLS versions and ciphers it supports, and sends its half of a key exchange.

The key exchange makes the connection private; the certificate proves you reached the right server. HTTPS needs both.

With TLS 1.3 the handshake costs one round trip on top of connecting. Browsers use port 443 for HTTPS, where plain HTTP uses port 80.

What TLS protects

Once the handshake finishes, everything inside the connection is encrypted:

  • the path and query string (/orders?id=42);
  • every header, including cookies and Authorization tokens;
  • the body: form fields, passwords, JSON, files.

Encryption comes with a check: if anyone alters a single byte in transit, the other side notices and drops the connection. That's why logins, API keys and session cookies should only ever travel over HTTPS.

What it doesn't protect

  • Which site you visit. The DNS lookup, the server's IP address and, usually, the name in the browser's hello are visible to the network. The page you open on it isn't.
  • Whether the site is honest. A certificate proves who controls a name, not that they're trustworthy. Phishing sites get valid certificates too.
  • Data at either end. TLS covers the trip. Once the server has your data, its security is the server's job; on your device, malware sees what you see.
Why the name in the hello is visible

One server address can host many sites, so the browser names the site it wants in its first message, before any keys exist. That field is called SNI. A newer extension, Encrypted Client Hello, hides it, but only where both the browser and the server support it.

Check yourself

You log in to https://shop.example.com on café Wi-Fi. What can the café's network see?
A link takes you to a login page with a valid HTTPS padlock. What does the padlock tell you?

In the docs