What is HTTPS?
Useful first: HTTP · optional, not a requirement
Choose your depth
Stay with the essentials, or look closer.
YOUR GOALSeparate a protected connection from a trustworthy website.
Protect the journey to the website.
A private conversation across a public network
Your browser and a website exchange requests and replies. HTTPS protects that exchange using TLS, a security system that scrambles the messages and detects changes made along the way.
Imagine sending a letter in a sealed envelope addressed to a particular shop. The envelope protects the journey. The shop still opens and reads the letter.
[1]A secure connection is one piece of the picture
An unfamiliar shop can use HTTPS and still make false promises. Check that you reached the intended website before trusting its requests.
Browsers show connection information in different ways. A particular padlock icon is not a universal requirement, and a security indicator does not certify the business.
[2]HTTPS protects the exchange; you still need to judge the destination.
HTTPS means a shop can be trusted.
It secures the connection. A dishonest shop can also use HTTPS.
Show the explanation
The connection is protected, but the shop still needs evaluation. Connection security does not verify the shop's promises or its handling of stored records.
YOUR GOALExplain encryption, integrity, and server authentication.
Three protections, with a specific scope.
What the browser establishes
For an HTTPS request, the browser needs a protected connection to a server authorized for the requested name.
- Confidentiality: outsiders cannot read the protected HTTP messages.
- Integrity: changes by a network attacker are detected.
- Authentication: the browser checks the server's identity for the destination.
These protections cover the exchange with that server, rather than everything the website does afterward.
[3]A certificate is tied to a name
A certificate links a public key to a domain. For example, Let's Encrypt requires proof of domain control before issuing one. That process does not evaluate the site's product claims.
If you intended to visit shop.example but opened shop-example.test, a valid certificate for the second name does not turn it into the first.
Server identity is separate from your account
Ordinary web TLS usually authenticates the server, not the visitor through a client certificate. A website can still require you to sign in.
[1]Check which domain the protected connection actually reaches.
A valid certificate confirms I reached the site I meant to visit.
It supports the requested domain's identity, which may differ from your intended destination.
Show the explanation
The connection can authenticate the domain actually requested. Domain validation concerns the name requested. It does not correct a typo or certify a relationship between shops.
YOUR GOALDistinguish authentication, traffic keys, and resource protection.
Identity and traffic protection have separate jobs.
Inside a full TLS 1.3 handshake
In a typical certificate-based TLS 1.3 handshake, the peers establish shared secret material. The server supplies its certificate and signs handshake data to prove possession of the corresponding private key. Derived symmetric traffic keys protect application messages.
The public certificate is not the page-encryption secret. This describes a full handshake, not every resumed connection.
[5]Encryption has endpoints
The receiving endpoint can read the messages. Transmitted lengths can remain observable to outsiders. Protecting content does not provide complete anonymity.
[5]Each resource needs protection
An HTTPS page can still reference an HTTP script. That is mixed content: the page's secure connection does not automatically protect another request.
Browsers block insecure script loads unless the request is upgraded to HTTPS. Some other resources, such as ordinary image requests, are automatically upgraded under mixed-content rules. Use HTTPS resource URLs directly.
[6]Authentication establishes identity; secret traffic keys protect the exchanged messages.
Anyone who obtains the public certificate can decrypt the page.
The certificate alone does not reveal the secret traffic keys.
Show the explanation
No; the certificate does not supply that connection's secret traffic keys. Public identity information and secret traffic keys have separate roles. Sharing a certificate does not share the connection's secrets.
Keep asking. Check the details.
Source-linked, AI-assisted draft. Human editorial review is still pending; this page is not presented as expert-reviewed.
- MDN — Transport Layer Security
- Chromium Blog — An Update on the Lock Icon
- RFC 9110 — HTTPS URI scheme and authenticated origins
- Let's Encrypt — How It Works
- RFC 8446 — TLS 1.3 handshake and record protection
- MDN — Mixed content