How HTTPS and TLS Protect a Website Connection

When a browser shows a padlock and the address starts with https, the page travels over a protected connection. That protection comes from a protocol called Transport Layer Security, or TLS. It gives a connection three things: secrecy, a check that data was not changed on the way, and proof of who the server is. This article explains each of the three, the part a certificate plays, and what the newest version, TLS 1.3, changed.

HTTPS is HTTP run over TLS

HTTP is the set of rules a browser and a web server use to ask for and send pages. On its own it sends everything in a form that anyone along the route can read. HTTPS is the same HTTP carried inside a TLS connection. According to Mozilla's web security documentation, TLS lets a client talk to a server across a network that cannot be trusted and still keep the exchange safe.

The network in between is made of many links: a home router, a café hotspot, the internet provider and many machines beyond. TLS is designed so that none of them needs to be trusted for the conversation to stay private.

The three protections

• Confidentiality. Data is encrypted in transit, so an outsider who captures it sees scrambled bytes rather than readable content.
• Integrity. If anyone changes data on the way, the change is detected.
• Authentication. Each side can prove who it is. On the web, the server proves its identity to the browser. The browser usually does not prove its identity to the server.

The standard that defines TLS 1.3, RFC 8446 from the Internet Engineering Task Force, states the same goal in its own words: communication designed to prevent eavesdropping, tampering and message forgery. In TLS 1.3 the server is always authenticated, while authenticating the client is optional.

What happens when a connection starts

Before any page content is sent, the browser and server run a short exchange called the handshake. Mozilla describes its purpose: the two sides agree on a TLS version, agree on a set of algorithms called a cipher suite, optionally check each other's identity, and arrive at a shared secret key. That key is then used to encrypt everything that follows.

The shared key is the clever part. The two sides never send the key itself across the network. They exchange enough information to each work it out, in a way that an observer cannot repeat. The details are mathematical, but the outcome is simple: both ends hold a key that nobody in the middle holds.

Where the certificate fits in

Encryption alone is not enough. A connection could be perfectly encrypted and still lead to an impostor. To prevent that, a website has a digital certificate that ties its public key to its domain name. The browser checks the certificate during the handshake, which is how the authentication protection works.

Certificates are issued by organisations called certificate authorities. Let's Encrypt is one that issues certificates free of charge. Its documentation says it issues Domain Validation certificates only. That means a certificate confirms that whoever requested it controls the domain name. It does not confirm the identity of the company or person behind the site, because Let's Encrypt does not offer Organisation Validation or Extended Validation certificates.

Certificates also expire. Per Let's Encrypt's FAQ, its default certificates last 90 days, and it also offers short-lived certificates that last six days. It recommends renewing the 90-day kind about every 60 days. The site's own server creates and keeps the private key; Let's Encrypt says it never generates or stores those keys.

What changed in TLS 1.3

Mozilla describes TLS 1.3 as the current version and the most widely used. TLS 1.2 is still used by some sites, while TLS 1.1 and 1.0 should no longer be used. RFC 8446 lists how version 1.3 differs from 1.2:

• The full handshake takes one round trip before application data can flow. An optional 0-RTT mode lets a returning client send early data in its first message, though the RFC notes this comes with weaker security guarantees.
• Older encryption methods were removed, leaving only a modern type called AEAD ciphers.
• Static RSA and static Diffie-Hellman key exchange were removed, so every key exchange provides forward secrecy. In plain terms, recording today's traffic and stealing the server's key later does not let an attacker read the recording.
• Features such as compression were dropped.
• Most handshake messages after the server's first reply are encrypted.

Taken together, version 1.3 has fewer options than version 1.2. Removing old choices reduces the number of ways a connection can be set up badly.

What a site owner adds on top

Mozilla recommends that all sites serve every page and every file they load over HTTPS. A page that is secure but loads one script over plain HTTP is called mixed content, and browsers block or upgrade such requests. A site can also redirect plain HTTP requests to HTTPS using a 301 response, and send a header called Strict-Transport-Security so that browsers go straight to HTTPS on later visits. That helps guard against an attack known as SSL stripping, where an attacker quietly keeps a visitor on the unprotected version.

What HTTPS does not do

TLS protects data while it moves between the browser and the server. It does not protect data once it arrives. A server that stores or shares your information carelessly is not made safe by HTTPS. It also does not hide which site you are visiting from every observer. This is general information, not security advice for a particular situation.

Sources

• Transport Layer Security (TLS), MDN Web Docs, Mozilla
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, IETF
• FAQ, Let's Encrypt