HTTP vs HTTPS: Encryption, Certificates, and How HTTPS Works

HTTPS is HTTP protected by TLS encryption and server authentication. Plain HTTP provides no comparable protection for traffic in transit. With HTTPS, the browser checks the server's certificate and establishes an encrypted connection before exchanging protected web requests and responses. RFC 9110 defines the two URL schemes and their security requirements.

This article explains what HTTPS actually does, and walks through the concepts it is built from: encryption, ports, certificates, certificate authorities, and the ACME protocol that now automates the issuance of most of the world's certificates. It ends where every HTTPS chain ends if you follow it far enough down: at control of a domain name.

What plain HTTP leaves exposed

These are connection properties, not a promise that a site is safe to buy from. HTTPS protects communication with the named host; a phishing site can also use HTTPS.

HTTP, the protocol browsers and web servers speak, was designed as cleartext. A request for a page, the cookies attached to it, the form data in it, and the page that comes back all travel across the network as readable bytes. Anyone positioned on the path — the operator of a coffee-shop Wi-Fi network, an ISP, a backbone carrier, a compromised router — can read all of it.

Worse, they can change it. Cleartext HTTP has no integrity protection, so an intermediary can inject advertising into pages, rewrite a download link to point at malware, or swap the account number on a payment page, and neither side can tell. And because plain HTTP has no notion of server identity, the browser is simply trusting that whatever machine answered — usually whatever IP address the DNS lookup returned — really is the site it asked for. As our case studies of DNS hijacking incidents show, that assumption fails in practice, and it fails expensively.

The three guarantees of HTTPS

HTTPS wraps HTTP in TLS — Transport Layer Security — whose current version, TLS 1.3, was standardized in 2018 as RFC 8446. The specification states the goal directly: TLS lets applications communicate in a way designed to prevent eavesdropping, tampering, and message forgery. Those three verbs map to three concrete guarantees:

• Confidentiality. The traffic is encrypted, so an observer on the path sees only which server you connected to and roughly how much data moved — not the URLs, cookies, credentials, or content.
• Integrity. TLS authenticates protected traffic with a cryptographic integrity check, so altered data is rejected rather than silently delivered. Modern TLS uses authenticated encryption; this is more specific than simply attaching a hash to a message.
• Authentication. The server proves possession of the private key for a certificate the browser trusts for the requested hostname. That is authentication of the connection, not proof of rightful domain ownership or an honest business. Mandiant documented DNS hijackers obtaining valid certificates for redirected services, allowing browsers to connect without certificate errors.

A useful way to remember the division of labor: encryption seals the envelope, integrity checks detect alterations, and authentication checks the recipient's certificate and proof of its private key against the requested hostname.

Ports: the internet's door numbers

An IP address identifies a machine, but a machine runs many networked programs at once. A port is the number, from 1 to 65535, that identifies which program a connection is for — the apartment number after the street address. A web server, a mail server, and an SSH daemon can share one machine because each listens on its own port.

The IANA port registry assigns well-known defaults so clients don't have to guess: port 80 for HTTP, and port 443 — registered as "http protocol over TLS/SSL" — for HTTPS. That is why URLs don't mention them; when a browser opens https://example.com, the default port is 443 unless the URL says otherwise.

One caveat worth knowing: encrypting traffic on port 443 does not make the connection invisible. An observer still sees which IP you connected to, and the TLS handshake has historically sent the server's hostname (the SNI field) unencrypted — any intermediary can view which website you're visiting simply by checking the first packet for a connection, as Cloudflare puts it. Encrypted Client Hello (ECH) is the emerging fix, and encrypted DNS closes the parallel leak on the lookup side — a shift with its own consequences, which we cover in DNS over HTTPS vs enterprise split-horizon DNS.

Inside the TLS handshake

Encryption comes in two flavors, and HTTPS needs both. Symmetric encryption uses one shared key for both sealing and opening messages — fast, but it assumes the two sides already share a secret, which strangers on the internet do not. Asymmetric (public-key) cryptography solves that bootstrap problem: the server holds a private key, publishes the matching public key, and anything encrypted to the public key can only be opened with the private one, while a digital signature made with the private key can be verified by anyone holding the public one.

The TLS handshake is the choreography that combines them. In brief:

1. The browser opens a connection and announces what cryptography it supports.
2. The server responds with its certificate — its public key, bound to its domain name, vouched for by a certificate authority.
3. The browser verifies the certificate (more on that next) and the two sides use asymmetric key-agreement to derive fresh session keys that no eavesdropper can compute.
4. Everything after that — the actual HTTP requests and responses — is encrypted symmetrically with those session keys, at full speed.

A note on names: this protocol family began life as SSL (Secure Sockets Layer) in the 1990s, was renamed TLS when standardization moved to the IETF, and modern browsers now speak TLS 1.2 and 1.3 only. The old name survives in everyday phrases like "SSL certificate," which today always means a TLS certificate.

Certificates and certificate authorities

Encryption without identity would be a private conversation with a possible impostor. The identity half of HTTPS rests on certificates: signed digital documents that bind a domain name to a public key. The signer is a certificate authority (CA) — an organization whose own signing keys are pre-trusted by browsers and operating systems through their root stores. Trust flows down a chain: a root CA signs an intermediate, the intermediate signs the certificate for example.com, and the browser accepts the site's key because the chain terminates in a root it already trusts — cryptographic security by delegation.

Before signing, the CA must validate that the requester actually controls the domain named in the certificate — that validation is the entire meaning of a standard (domain-validated) certificate. If a browser receives a certificate that doesn't chain to a trusted root, doesn't match the hostname, or has expired, it interrupts the page with a full-screen warning instead of the padlock.

That warning is not theater. In the 2018 MyEtherWallet attack, attackers hijacked internet routing and DNS so thoroughly that victims' browsers fetched a pixel-perfect phishing clone from the attackers' server — but the one thing the attackers could not do was get a trusted CA to sign a certificate for myetherwallet.com. Every victim saw a certificate warning; the users who lost funds were the ones who clicked through it.

Two developments keep the CA system honest at scale. Certificate Transparency (RFC 6962) records issued certificates in public, append-only logs — a protocol for publicly logging the existence of TLS certificates — so a domain owner can monitor the logs and detect a certificate issued for their name that they never requested. And certificate lifetimes keep shrinking: under CA/Browser Forum Ballot SC-081v3, adopted in April 2025, the maximum validity of a public TLS certificate — 398 days for most of the CA/Browser Forum's history — dropped to 200 days on March 15, 2026, and steps down again to 100 days in March 2027 and 47 days in March 2029, shrinking the window during which a stolen or mis-issued certificate stays dangerous. Nobody will renew certificates by hand every six weeks — which is why the last piece matters most.

ACME: certificates on autopilot

For the web's first two decades, getting a certificate meant paying a CA, generating a signing request by hand, proving control of the domain over email, and repeating the ritual every year or two. The cost and friction showed: as late as February 2018, Google's telemetry put Chrome traffic on Android and Windows at just over 68% protected.

ACME — the Automatic Certificate Management Environment, standardized in 2019 as RFC 8555 and pioneered by the nonprofit CA Let's Encrypt — removed both the cost and the friction. It is a protocol a CA and an applicant use to automate the process of verification and certificate issuance. An ACME client (such as EFF's Certbot) proves control of a domain by completing a challenge, and Let's Encrypt's documentation describes the two that matter:

• HTTP-01: the CA hands the client a token, and the client puts a file on your web server at http://<your-domain>/.well-known/acme-challenge/<token>. If the CA can fetch it from the public internet, whoever runs that server controls the domain. This challenge cannot be used to issue wildcard certificates.
• DNS-01: the client proves control of the domain's DNS by putting a specific value in a TXT record at _acme-challenge.<your-domain>. Because it demonstrates control of the zone itself, this is the challenge that can issue wildcard certificates covering every subdomain.

Issuance and renewal then run on a timer with no human involved. The result is one of the quietest infrastructure victories of the modern internet: Let's Encrypt reports it is now frequently issuing ten million certificates per day and on track to serve a billion active sites. Encryption went from a paid add-on to the default state of the web.

Notice what both challenges have in common: the only identity being verified is control of a domain name — via its web server or via its DNS zone. In the HTTPS trust model, the domain is the identity.

Why HTTPS became non-negotiable

The browsers did not wait politely for adoption. Beginning in July 2018 with the release of Chrome 68, Chrome marked every plain-HTTP page "not secure" in the address bar, and other browsers followed the same arc. Google had already put a thumb on the scale years earlier, announcing in August 2014 that it was starting to use HTTPS as a ranking signal in search — only a very lightweight signal at the time, but a clear statement of direction.

Two more mechanisms lock the ratchet. HSTS (HTTP Strict Transport Security, RFC 6797) lets a site declare itself accessible only via secure connections: once a browser has seen that header, it refuses to load the site over plain HTTP again for as long as the declared max-age policy stays cached — a first-ever visit, or one after the policy expires, isn't covered unless the domain is also on browsers' hardcoded HSTS preload list. And browser vendors gate modern web capabilities to secure pages — in Chrome's words, HTTPS unlocks both performance improvements and powerful new features that are too sensitive for HTTP. For any domain that serves users, HTTPS stopped being a security upgrade and became the price of admission.

What HTTPS does not do

Clarity about the guarantees requires clarity about the gaps:

• It does not vouch for the site's honesty. A domain-validated certificate proves you reached the domain in the address bar — not that the domain is trustworthy. Phishing sites routinely serve valid HTTPS on lookalike domains they legitimately registered. The padlock means private, not safe.
• It does not hide that a connection happened. Destination IPs, timing, traffic volume, and (until ECH is universal) the SNI hostname remain observable metadata.
• It does not protect data at rest. TLS secures the pipe; a breached or malicious server exposes whatever you sent regardless of how well it was encrypted in transit.
• It is only as strong as control of the domain. ACME's challenges are honest about the trust model: whoever controls a domain's DNS or its registrar account can pass validation and obtain flawless, browser-trusted certificates for it. A domain hijacker doesn't need to break TLS — they become the identity TLS attests to, as our breakdown of how domain hijacking actually happens shows with real incidents.

The domain is the root of the chain

Follow HTTPS all the way down and every guarantee bottoms out in the same place. The certificate names a domain. The CA validated control of that domain. The ACME challenge was answered by that domain's web server or nameservers. Encryption, integrity, authentication — all of it is anchored not in the server hardware or the company behind the site, but in the domain name and the DNS that steers it.

That is why domain security is not adjacent to HTTPS — it is underneath it. Protecting the registrar account, locking transfers, controlling who can edit DNS records: these are certificate-security measures, whether or not they are labeled that way. It is also the lens behind how Namefi approaches domains: treating the domain as a first-class, verifiable asset — with tokenized ownership that can be cryptographically proven — hardens the layer that every certificate authority, every ACME challenge, and every padlock ultimately relies on.

The padlock is the last link in the chain. The domain is the first.

Sources and further reading

• IETF — RFC 9110, sections 4.2.1–4.2.2, HTTP/HTTPS schemes, default ports, confidentiality, integrity, and authentication. Fetched 2026-09-15.

• IETF — RFC 9110, section 4.3.3, HTTPS authority based on certificate trust and use of the corresponding private key. Fetched 2026-09-15.

• Mandiant — Global DNS Hijacking Campaign: DNS Record Manipulation at Scale, technique 1, steps 6–7: attackers obtaining certificates after changing DNS records. Fetched 2026-09-15.

• IETF — RFC 2818: HTTP Over TLS — defines HTTPS and the default port 443.

• IETF — RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018).

• IETF — RFC 8555: Automatic Certificate Management Environment (ACME) (March 2019).

• IETF — RFC 6962: Certificate Transparency and RFC 6797: HTTP Strict Transport Security.

• IANA — Service Name and Transport Protocol Port Number Registry — the port 443 registration.

• Let's Encrypt — Challenge Types and 10 Years of Let's Encrypt Certificates (December 2025).

• Chromium Blog — A secure web is here to stay (February 2018).

• Google Search Central — HTTPS as a ranking signal (August 2014).

• CA/Browser Forum — Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (April 2025); schedule detail via DigiCert — TLS Certificate Lifetimes Will Officially Reduce to 47 Days.

• Cloudflare — Encrypted Client Hello: the last puzzle piece to privacy (September 2023).

• EFF — Certbot, the ACME client.