What HTTPS does
HTTPS is HTTP sent inside an encrypted TLS (Transport Layer Security) connection. Before any page data moves, TLS checks the server's certificate to confirm you reached the domain you asked for. It then agrees on fresh keys that encrypt every byte in both directions and reveal any tampering.
That gives you confidentiality, integrity and server authentication while data is in transit. SSL is the older name for the same family of protocols. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are all deprecated, and major browsers now connect only with TLS 1.2 or TLS 1.3.
The TLS 1.3 handshake, step by step
A TLS 1.3 handshake needs one round trip between browser and server before encrypted application data can flow. The steps below are simplified, but each one is part of the protocol defined in RFC 8446.
- ClientHello: the browser lists the TLS versions and cipher suites it supports and sends a key share, its half of an ephemeral Diffie-Hellman key exchange.
- ServerHello: the server picks a cipher suite and sends its own key share. From the two shares, both sides compute the same secret without ever sending it over the network.
- Certificate and CertificateVerify: the server sends its certificate chain and a signature over the handshake, made with the certificate's private key. These messages are already encrypted with keys derived from the shared secret.
- Verification: the browser checks that the chain leads to a trusted root and that the certificate covers the hostname and is in date. It also checks the signature.
- Finished: both sides send a message confirming that nobody altered the handshake. The HTTP request and response now travel encrypted.
The certificate key signs, the session keys encrypt
In TLS 1.3 the certificate's public key is never used to encrypt a session key. Older TLS versions allowed that method (RSA key transport), and TLS 1.3 removed it. The certificate key only proves identity by signing the handshake.
The session keys come from the ephemeral Diffie-Hellman exchange and are thrown away after the connection. This is called forward secrecy: someone who records your traffic today and steals the server's private key next year still can't decrypt it.
After the handshake, both sides switch to symmetric authenticated encryption, such as AES-GCM or ChaCha20-Poly1305. The same key encrypts and decrypts, which is fast, and every record carries an authentication tag, so any modification is detected.
What HTTPS protects against
HTTPS protects the path between the browser and the server. On shared Wi-Fi, at an internet provider or anywhere else along the route, an attacker can't read passwords, cookies or page content. They also can't inject scripts or ads into a response without the browser noticing.
It hides more of each request than many people expect. The URL path, query string, headers and body are all encrypted. An observer still sees the server's IP address and, in most connections, the hostname, which is sent in the TLS Server Name Indication field.
What the padlock doesn't tell you
A padlock means the connection is encrypted to whoever controls that domain. It says nothing about whether the people running the site are honest. Phishing sites can get valid certificates as easily as anyone else, because domain-validated certificates are free and issued automatically.
HTTPS also stops at the server. It doesn't protect data once it arrives or remove malware from your device. Nor does it hide the sites you visit from your DNS resolver, unless DNS is encrypted too.
On your own site, redirect HTTP to HTTPS and send an HSTS header so browsers stop trying plain HTTP at all.