Internet Advanced: Security, Speed and Governance
TLS and Certificates in Depth
In this lesson you will
- Describe the main steps of a TLS 1.3 handshake
- Explain certificate chains and how browsers decide to trust a site
- Apply HSTS and sound certificate management practices
Introduction
TLS is the security layer under HTTPS, email, and much more. You have used it in the padlock lesson. Here we look at how it actually builds a trusted, encrypted channel between strangers over an open network.
What TLS must achieve
- Authenticate the server (and optionally the client): prove who is at the other end.
- Agree on keys for encryption, without an eavesdropper learning them.
- Protect all data afterwards for confidentiality and integrity.
The clever part is combining two kinds of cryptography. Asymmetric cryptography lets strangers agree on a secret and verify identities, but is slow. Symmetric cryptography with a shared key is very fast, so it encrypts the bulk of the data.
The handshake, simplified (TLS 1.3)
- ClientHello: the browser says which TLS versions and cipher suites it supports, and sends its half of a key exchange. It also sends the site name it wants (SNI), so a server hosting many sites knows which certificate to use.
- ServerHello: the server picks the settings and sends its half of the key exchange.
- Both sides can now compute the same shared secret, using a key exchange such as elliptic-curve Diffie-Hellman, without the secret itself ever crossing the network.
- The server sends its certificate and a signature proving it holds the matching private key. Everything from here on is already encrypted.
- The client checks the certificate (see below). Both confirm with Finished messages.
- Application data (the HTTP request) flows, encrypted with fast symmetric keys.
TLS 1.3 needs about one round trip, faster than older versions, and removed many weak options. Keys are fresh for each session, which gives forward secrecy: stealing the server's long-term key later does not reveal past conversations.
Quick quiz
Why does TLS use both asymmetric and symmetric cryptography?
Certificates and trust
A certificate binds a public key to a name, signed by a certificate authority (CA).
How your browser decides to trust it:
- Your operating system and browser contain a list of trusted root CAs.
- The server sends its leaf certificate plus any intermediate certificates, forming a chain: leaf, signed by an intermediate, signed by a root.
- The browser verifies each signature up to a trusted root, and checks that the certificate is valid for this hostname, not expired and not revoked.
- If anything fails, you get a warning. Do not click through warnings on sites you care about.
Roots are kept offline and rarely used directly. Intermediates sign the day-to-day certificates.
Getting and managing certificates
- Domain-validated certificates only prove control of the domain. Services such as Let's Encrypt issue them for free and automatically, using the ACME protocol.
- Certificate Transparency logs make every issued certificate publicly auditable, so wrongly issued ones can be spotted.
- Certificates are short-lived (months), so automate renewal. Expired certificates are a very common cause of outages.
- Keep private keys secret, and generate new ones when you renew or suspect exposure.
- If a key leaks, revoke the certificate and replace it.
HSTS
An attacker could downgrade a first request from HTTPS to plain HTTP. The HTTP Strict Transport Security header tells browsers to use HTTPS only for your site for a set time:
Strict-Transport-Security: max-age=31536000; includeSubDomainsTest carefully before enabling a long duration, because breaking HTTPS later would lock users out.
Good configuration
- Support TLS 1.2 and 1.3 only, and disable older versions.
- Use modern cipher suites, and let a well-known configuration generator guide you.
- Redirect HTTP to HTTPS, and serve the full certificate chain.
- Use a testing tool to grade your configuration.
- Mutual TLS (mTLS) has both sides present certificates, and is common for service-to-service traffic in zero-trust systems.
What TLS does not do
It does not hide who you are talking to (the destination address and often the site name are visible), and it does not make a site trustworthy. It protects the channel.
Try it yourself
In your browser, open the certificate details of a site you use. Find the issuer, the validity dates, the hostname list and the chain. Note when it will expire.
Summary
- TLS 1.3 uses a key exchange and certificate signature to set up a fresh, encrypted channel in about one round trip.
- Browsers trust a site if its certificate chains to a trusted root and matches the name, dates and status.
- Automate renewals, protect private keys, use HSTS and modern settings, and remember TLS secures the channel, not the site's honesty.
Lesson complete
+20 XP
Nice work. Keep going while it is fresh.