Every time you open a site whose address starts with https, the browser sets up a connection protected by TLS (Transport Layer Security). Within a few milliseconds a key exchange, an identity check and the start of encryption all take place. Understanding these phases helps you know what the padlock really guarantees and what it does not guarantee at all.
The three goals of TLS
TLS aims to achieve three things:
- confidentiality: nobody along the path can read the data being exchanged;
- integrity: nobody can modify it without the change being detected;
- server authentication: you really are talking to the site shown in the address bar, not to an impostor.
HTTPS is not a different protocol from HTTP: it is simply HTTP carried inside a TLS connection.
The TLS 1.3 handshake, step by step
The current version, TLS 1.3, greatly simplified the protocol compared with its predecessors and removed the weakest algorithms. The initial phase, called the handshake, goes like this.
1. The client says hello
The browser sends a message called ClientHello, which contains:
- the protocol versions and encryption algorithms it supports;
- a random number;
- an ephemeral public key, generated on the spot, for the key exchange (usually on an elliptic curve such as X25519);
- the name of the site it wants to reach.
2. The server responds
The server picks the algorithms and sends its own ephemeral public key; from that moment both sides can compute the same shared secret using the Diffie-Hellman method. The secret never travels over the network.
Immediately afterwards, already in encrypted form, the server sends:
- its certificate and the intermediate ones;
- a signature, produced with the certificate's private key, over all the messages exchanged so far;
- a closing message confirming the integrity of the handshake.
3. The client verifies
The browser checks that the certificate is valid, that it was issued for that domain, that the chain leads back to a trusted authority and that the server's signature is correct. This proves the server holds the certificate's private key. If everything checks out, it sends its own closing message.
The entire TLS 1.3 handshake needs only one round trip between client and server, compared with two in earlier versions.
After the handshake: encrypting the data
Session keys are derived from the shared secret and used with an authenticated symmetric algorithm such as AES-GCM or ChaCha20-Poly1305. Every data packet is encrypted and carries an authentication tag: if someone alters even a single bit, the recipient notices and discards the packet.
Because the ephemeral keys are deleted at the end of the session, TLS 1.3 always provides forward secrecy: even if the server's certificate private key were stolen in the future, past conversations recorded by an attacker would remain undecipherable.
What HTTPS protects and what it does not
| Protected | Not protected |
|---|---|
| Content of pages and forms | The fact that you are connecting to that server |
| Passwords and data you enter | The domain name, in many cases |
| Full address path and parameters | The amount of data and timing of the connection |
| Session cookies | The honesty of the site itself |
Two points deserve attention:
- The padlock does not certify that the site is trustworthy. It only says that the connection to that domain is encrypted and authentic. A fraudulent site with a domain resembling a bank's can have a perfectly valid padlock.
- Encryption runs between you and the server, no further. Once the data reaches the server, it is in plain text for whoever runs it.
Versions and configurations to avoid
SSL, TLS 1.0 and TLS 1.1 are considered obsolete and modern browsers no longer accept them. Server administrators should enable TLS 1.2 and 1.3, disable outdated algorithms and turn on HSTS, a header telling the browser to always connect to that domain over HTTPS only, preventing a downgrade to an unencrypted connection.
When the browser warns you
An invalid-certificate warning may be due to a trivial mistake, such as an expired certificate, but it can also signal an interception attempt. On public networks and on sites where you enter credentials the rule is simple: do not continue. Clicking "proceed anyway" means giving up precisely the guarantee of authenticity that TLS exists to provide.
In short
- HTTPS is HTTP protected by TLS, which guarantees confidentiality, integrity and server authentication.
- The TLS 1.3 handshake uses an ephemeral key exchange and the server's signature backed by its certificate.
- Data then travels under authenticated symmetric encryption such as AES-GCM.
- Ephemeral keys ensure forward secrecy for past sessions.
- The padlock does not prove the site is honest: it only proves who you are talking to.
