How does HTTPS establish a protected connection to a website?

HTTPS carries HTTP messages through a connection protected by Transport Layer Security, or TLS. Before ordinary application data is exchanged, the browser and server carry out a handshake. In a common TLS 1.3 case, they agree on cryptographic choices and exchange temporary key-agreement information.

The server presents a certificate associated with the site’s name and proves possession of its corresponding private key through a handshake signature. The browser checks the name, validity and certificate chain under its trust rules. A certificate is part of authenticating an endpoint, not evidence that the page tells the truth.

Key agreement and a key-derivation process let the endpoints obtain traffic keys without sending those keys openly across the network. Symmetric authenticated encryption then protects application records for confidentiality and integrity. The server's private key associated with its certificate signs handshake information; the separately derived traffic keys protect the application records. These are different jobs.

This protection is between the TLS endpoints. A compromised endpoint can still expose data, and an authenticated site can still publish misleading content. Modern TLS also should not be pictured as encrypting an entire browsing session directly with a server’s RSA public key: TLS 1.3 uses a different handshake design, with several allowed modes.