How HTTPS keeps you safe
TLS is the protocol behind the padlock. It combines asymmetric cryptography (to authenticate and exchange keys) with symmetric encryption (to protect the traffic).
In this lesson
- List the goals of the TLS handshake
- Explain the role of Certificate Authorities
- Recognise common HTTPS failures
Three goals in one handshake
-
1
Hello & supported ciphers
Client and server agree on TLS version and cipher suites.
-
2
Certificate check
Server sends its certificate chain; client verifies it up to a trusted root CA and that it matches the domain.
-
3
Key exchange
Ephemeral keys (X25519) derive a shared session secret — forward secrecy: a stolen server key cannot decrypt yesterday's traffic.
-
4
Session keys
Both sides derive symmetric AES-GCM keys and start encrypting.
-
5
Application data
Every HTTP request and response now travels encrypted and authenticated.
The certificate step is where public key cryptography does the trust work: a Certificate Authority signs the site's public key, and your browser validates that signature against roots it already trusts.
Example · What the padlock actually means
It says: the connection is encrypted and the server's identity matched a certificate for this domain. It says nothing about whether the site is honest — phishing sites have valid certificates too.
Warning signs
"Not secure" (HTTP), certificate name mismatches, expired certificates, or a chain anchored to an unknown root — all mean stop. Never bypass certificate warnings on login pages.
See the exchange
Use the key-pair lab to watch a shared secret appear on both sides from public material alone.
Does HTTPS make a site safe?
No — it makes the <em>connection</em> safe. Site honesty, malware and phishing are separate problems.
What is forward secrecy?
Session keys are derived from ephemeral keys discarded after the handshake, so recorded traffic stays unreadable even if the server's long-term key leaks later.