How Does HTTPS Work? The TLS Handshake, Step by Step

Key takeaways

• HTTPS is ordinary HTTP wrapped in TLS. The web pages and headers are the same; only the transport changes.
• The TLS handshake does three jobs: agree on algorithms, prove the server's identity with a certificate, and create fresh session keys.
• Public-key cryptography is used briefly during the handshake. The bulk of your data is protected with fast symmetric encryption.
• The padlock means the connection is encrypted and the domain matches the certificate. It does not mean the site is honest or safe.
• You can watch the handshake yourself with openssl, curl or Wireshark.

What is HTTPS, in one picture?

HTTPS means HTTP over TLS. TLS (Transport Layer Security) sits between TCP and HTTP. Your browser still sends GET /login and the server still replies with HTML, but both messages travel inside an encrypted tunnel. The older name SSL is still used casually, but SSL 2.0 and 3.0 are long retired. Today's connections use TLS 1.2 or TLS 1.3, defined in RFC 8446 for 1.3.

TLS gives you three guarantees:

• Confidentiality: an eavesdropper on Wi-Fi or at an ISP sees only scrambled bytes.
• Integrity: if someone changes a byte in transit, the receiver detects it.
• Authentication: the browser checks that it is talking to the real owner of the domain.

What happens when you open an HTTPS website, step by step?

Seven things happen before the first byte of the page is shown. The names below follow TLS 1.3, which is what most modern sites negotiate.

1. DNS lookup. The browser turns www.example.com into an IP address. DNS itself is a separate protocol and is not protected by HTTPS unless you use DNS over HTTPS or DNS over TLS.
2. TCP connection. A normal three-way handshake (SYN, SYN-ACK, ACK) opens a connection to port 443.
3. ClientHello. The browser sends the TLS versions and cipher suites it supports, a random value, the server name it wants (SNI), and its half of a key exchange (a public value, usually from X25519).
4. ServerHello. The server picks a cipher suite and sends its own key-exchange value. At this point both sides can compute the same shared secret, and everything after this message is already encrypted in TLS 1.3.
5. Certificate and signature. The server sends its certificate chain and signs the handshake transcript with its private key. This is the proof that it owns the certificate.
6. Browser validation. The browser checks that the certificate chains to a trusted root, has not expired, covers the domain name, and has not been revoked.
7. Finished messages. Each side confirms the handshake was not tampered with. Application data (your HTTP request) now flows, encrypted with keys derived from the shared secret.

TLS 1.3 needs one round trip for a new connection. TLS 1.2 needs two, and it sends the certificate in the clear, which is one reason 1.3 is better for privacy.

Why does HTTPS use both public-key and symmetric encryption?

Public-key methods solve the hard problem of agreeing on a secret with a stranger over an open network, but they are slow. Symmetric ciphers such as AES-GCM or ChaCha20-Poly1305 are very fast but need both sides to already share a key. TLS uses key exchange (Diffie-Hellman style) once to create that key, then switches to symmetric encryption for everything else. In TLS 1.3 the key exchange is ephemeral, so a new key is made for each connection. If the server's private key leaks later, old recorded traffic still cannot be decrypted. This property is called forward secrecy.

What does the certificate actually prove?

A certificate binds a domain name to a public key and is signed by a certificate authority (CA) that browsers trust. It proves that whoever controls the private key also controlled the domain when the certificate was issued. It does not say who the business is, whether it is legitimate, or whether the content is safe. Phishing sites routinely get valid certificates, so the padlock only tells you the connection to that exact domain is private.

How can you see the handshake yourself?

Reading about it is fine, but seeing it makes it stick. Use a domain you own or any public site you are only reading from; these commands just connect normally.

openssl s_client -connect example.com:443 -servername example.com -tls1_3

This prints the certificate chain, the negotiated protocol (look for TLSv1.3) and the cipher suite, for example TLS_AES_256_GCM_SHA384.

curl -vI https://example.com

The verbose output shows lines starting with * for the TLS exchange: the version, cipher, server certificate subject, issuer and expiry date.

In Wireshark, capture on your network interface and apply the display filter tls.handshake. You will see ClientHello and ServerHello in the clear. In TLS 1.3 the certificate is encrypted, so you will not see it unless you load session keys (the SSLKEYLOGFILE method described in the Wireshark documentation). Practise this only on your own machine and traffic.

What happens if a site does not use HTTPS?

On plain HTTP, anyone between you and the server can read form fields, cookies and pages, and can inject content such as ads or scripts. On public Wi-Fi this is easy to do. Login cookies sent over HTTP can be copied and reused. Browsers now mark HTTP pages as "Not secure", and many features, such as service workers and geolocation, require HTTPS.

Common mistakes and misunderstandings

• "Padlock means safe." It means encrypted to that domain. Always read the domain.
• Mixed content. An HTTPS page that loads a script over HTTP can be attacked through that script. Browsers block most of it, but fix it at the source.
• Forgetting renewal. Expired certificates take sites down. Automate renewal, for example with ACME clients.
• Missing HSTS. Without the Strict-Transport-Security header, a first request over HTTP can be intercepted and downgraded.
• Thinking HTTPS hides everything. The IP address, the timing, and usually the server name (SNI) remain visible to the network.

Does HTTPS slow a site down?

The handshake adds a round trip or two on a new connection, and encryption costs a little CPU. With TLS 1.3, session resumption and HTTP/2 or HTTP/3, the difference is small for ordinary sites, and many sites become faster because HTTP/2 requires TLS in browsers. Measure with your own pages rather than trusting a fixed number.

Next steps

If you want to understand certificates, ciphers and attacks like downgrade and man-in-the-middle in depth, the networking and security modules in our computer networking course and cyber security course cover them with labs. For related reading, see how an SSL/TLS certificate works and the beginner guide to SSL/TLS.