What happens when a browser opens an HTTPS site for the first time?

Answer

The browser resolves the hostname, opens TCP, then runs a one-round-trip TLS 1.3 handshake. It agrees fresh encryption keys and checks the server's identity before any request is sent.

The browser sends its key share inside ClientHello, so one round trip is enough.¹
After ServerHello everything is encrypted, including the server's certificate.¹
CertificateVerify proves the server holds the certificate's private key.
Keys come from ephemeral shares, so a later leak of the private key cannot decrypt this session.

Applies toTLS 1.3 over TCPfirst visit to a hostno proxy, no resumption

What crosses the wire before the first request?

First HTTPS visit: DNS to first response

Diagram structure

Browser browser
DNS resolver dns
Web server server
browser → dns · DNS query: example.com
dns → browser · IP address
browser → server · SYN
server → browser · SYN + ACK
browser → server · ACK
browser → server · ClientHello: suites, SNI, key share
server → browser · ServerHello: chosen suite, key share
server → browser · Certificate + CertificateVerify + Finished, encrypted
browser → server · Finished
browser → server · GET /
server → browser · 200 OK + page

DNS resolver
Turns the hostname into an IP before the connection can start.
Browser
Opens TCP and sends ClientHello with TLS 1.3, cipher suites, the hostname and an ephemeral key share.
Web server
Sends its key share, then certificate and Finished under encryption; checks the client's Finished.

How does the browser know this is the real site?

Check	What the browser verifies
Chain	The certificate chains to a root CA in the browser's trust store.
Hostname	The site's name appears in the certificate's subject alternative name (SAN) list.
Validity	Today sits inside the certificate's not-before and not-after dates.
Ownership	`CertificateVerify` signs the handshake transcript; only the private-key holder could produce it.
Revocation	WeakStapled OCSP or CRLs, checked best-effort; many browsers accept an unreachable check.

Where do the session keys come from?

Key shares: Each side sends an ephemeral Diffie-Hellman share, usually X25519.
Shared secret: Each side combines its private share with the peer's public share.
Key schedule: HKDF expands the secret plus the transcript into handshake, then traffic keys.
Forward secrecy: Shares are discarded after use, so later key theft cannot decrypt this session.
Client Finished: Confirms both sides hold the same keys; the request can now ride on them.

What changes on the next visit?

Aspect	First visit	Resumed visit
Server proof	Full certificate and signature check	Pre-shared key from a `NewSessionTicket`
Round trips to first byte	DNS + TCP + 1 RTT of TLS	0-RTTTCP, then data can ride with `ClientHello`
Early data risk	None; the request waits for `Finished`	Replayable0-RTT data can be replayed, so servers limit what it may do