Defaults.Exposed

Defaults.Exposed › Reports

What Is HTTPS? How the Secure Web Actually Works

Published

HTTPS is ordinary web traffic — the same HTTP requests and responses your browser has always sent — wrapped inside an encrypted, authenticated channel called TLS. That wrapper does three jobs at once: it encrypts the traffic so nobody between you and the site can read it, it checks the site’s identity against a certificate so you are talking to the real server and not an impostor, and it protects integrity so the page cannot be silently altered in transit. It is the security baseline the modern web is built on, which is why browsers now brand anything without it “Not Secure.” And yet the August 2026 defaults.exposed census, an independent scan of 432,127,908 domains, found 44 million of them still answering on plain HTTP with no encryption at all. This guide explains exactly what HTTPS is, how the handshake behind it works, what the padlock does and does not prove, and how to check whether your own site is properly protected.

Most people meet HTTPS as a padlock, a green flash, or a scary warning — signals the browser shows and then hides again. Underneath those signals is a precise piece of engineering that has quietly become the single most important control on the web. Understanding it is the difference between assuming you are covered and knowing it. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What HTTPS means (and what the padlock does not prove)

HTTPS stands for Hypertext Transfer Protocol Secure. The “secure” is not a separate protocol — it is HTTP running over TLS (Transport Layer Security), the successor to the older SSL. When a URL begins with https://, your browser has agreed a TLS session with the server before a single byte of the actual web request is sent. Everything after that — the page you asked for, the form you submitted, the cookie that keeps you logged in — travels inside that session.

TLS gives an HTTPS connection three properties, and it is worth separating them because people routinely collapse all three into the word “secure”:

Here is the part that trips up almost everyone. The padlock proves the connection, not the character of the site behind it. A valid certificate confirms that the traffic is encrypted and that you are genuinely connected to the hostname in the address bar. It says nothing about whether that hostname belongs to an honest business. Phishing sites use HTTPS too — a criminal can obtain a free, valid certificate for a look-alike domain in minutes. The padlock means “this channel is private and goes where it claims,” not “this website is trustworthy.”

Browsers have quietly acknowledged this. The padlock icon that once implied safety has been demoted — most browsers now show a neutral settings or “tune” glyph instead, precisely because a generation of users had been taught to read the padlock as an endorsement it was never designed to be. HTTPS is necessary for trust. It is not sufficient for it. For how defaults.exposed grades whether a domain even offers an HTTPS connection in the first place, see the HTTPS availability methodology.

How the HTTPS/TLS handshake works, step by step

Before any web content moves, the browser and server run a short negotiation called the TLS handshake. Its goal is to agree on shared encryption keys over a network that is assumed to be hostile — a stranger listening to every packet must not be able to derive those keys. Modern HTTPS uses TLS 1.3 (RFC 8446), which streamlines the older TLS 1.2 exchange considerably. Here is what happens.

  1. TCP connection. The browser opens a normal TCP connection to the server, usually on port 443 — the reserved HTTPS port, as opposed to port 80 for plain HTTP.
  2. ClientHello. The browser sends its opening message: the TLS versions it supports, the list of cipher suites it can use, and — in TLS 1.3 — a key share, a piece of public key material generated for this session only. Sending the key share up front is the trick that lets TLS 1.3 finish in a single round trip.
  3. ServerHello and certificate. The server replies with the version and cipher suite it has chosen, its own key share, and its certificate — the signed document binding its public key to its hostname. From the two key shares, both sides independently compute the same shared secret using an ephemeral Diffie-Hellman exchange, so the actual session key never crosses the wire.
  4. Certificate validation. The browser checks the certificate: that it was issued by a trusted CA, that it is valid for the exact hostname requested, that it has not expired, and that it has not been revoked. If any check fails, the browser stops and shows a certificate error rather than proceeding.
  5. Finished. Both sides confirm they have derived matching keys and switch to encrypted communication. Only now does the browser send the real HTTP request — GET / and the rest — inside the encrypted tunnel.

Two properties are worth naming. Because the keys are ephemeral — freshly generated per session and thrown away afterwards — recording today’s encrypted traffic and stealing the server’s long-term key tomorrow does not decrypt it. This is forward secrecy, and it is mandatory in TLS 1.3. And because the handshake in TLS 1.3 completes in one round trip rather than the two that TLS 1.2 required, HTTPS is now typically faster to establish than the folklore that “encryption is slow” suggests. The version and cipher a server negotiates are themselves gradeable posture; defaults.exposed measures them in the TLS version methodology.

HTTP vs HTTPS: what changes on the wire

The clearest way to understand HTTPS is to watch what happens to a single request with and without it.

Over plain HTTP (port 80), a request for your account page travels as readable text. Every device on the path — the Wi-Fi access point, other users on the same network, the ISP, any transit provider — can read the full URL, the cookies that authenticate your session, and any data you submit. Worse, they can change it: inject an advertisement, rewrite a download link to point at malware, or strip a security feature, and neither you nor the server can tell. HTTP offers no confidentiality, no authentication, and no integrity. It was designed in an era when the network between two computers was assumed to be trustworthy, an assumption that has not held for decades.

Over HTTPS (port 443), the identical request is sealed inside the TLS session established by the handshake above. An eavesdropper on the same path now sees only three things: the server’s IP address, the hostname being visited (via the SNI field and DNS lookups, unless further protections are in place), and the rough size and timing of the traffic. The URL path, the query string, the cookies, the form contents, and the response body are all encrypted. Tampering is detectable. Impersonation requires defeating the certificate system rather than simply being on the wire.

The distinction is not academic. Any credential entered over HTTP — a password, a card number, a session token — should be considered compromised the moment it is sent, because anyone in a position to observe the network has it in plaintext. This is exactly why browsers escalated from silently allowing HTTP, to warning on it, to marking every HTTP page “Not Secure.” A fuller side-by-side, including whether HTTP is ever acceptable, lives in HTTP vs HTTPS: what’s the difference, and is HTTP safe?.

How many sites actually use HTTPS in 2026 (census data)

If HTTPS is the baseline, the obvious question is how much of the web has actually reached it. The August 2026 census measured the whole reachable namespace, and the answer is more mixed than the “HTTPS everywhere” narrative suggests.

Of the 432,127,908 domains scanned, 231,991,983 presented a TLS certificate that defaults.exposed could evaluate — the practical HTTPS-serving population. That is the base against which every TLS and certificate figure in this report is measured. The gap between that number and the total is made up of parked domains, delegated-but-empty names, and servers that answer only on plain HTTP.

That last group is the headline. 44 million domains still serve plain HTTP with no encryption at all in 2026 — no certificate, no TLS, nothing between the visitor and the network. These are not obscure edge cases; they are live domains answering web requests in cleartext, a posture that browsers now flag on sight. The twin finding-led report walks through who they are and why the number is so stubborn in The HTTP-Only Problem: 44 Million Domains Serving Unencrypted Web in 2026.

A subtler failure sits alongside outright HTTP-only. 27 million domains answer on HTTP and never redirect the visitor to a secure version. A site can have a perfectly good certificate on port 443 yet still accept, and stay on, plain HTTP on port 80 — so a visitor who types the bare domain, or follows an old http:// link, is served the unencrypted version and never bounced up to HTTPS. The encryption exists; the site simply does not insist on it. That “last mile” gap is quantified in The Last Mile of HTTPS, and the redirect itself is graded in the HTTP-to-HTTPS redirect methodology.

Even among domains that do serve HTTPS, the certificate is not always sound. The census found 5.2 million domains still serving expired certificates — a certificate that lapsed but was never renewed, which triggers a browser error and breaks the very trust HTTPS is meant to provide — and 3.3 million serving self-signed certificates that no public CA vouches for. Presence of TLS, in other words, is the start of the measurement, not the end of it. The certificate has to be valid, current, and issued by a trusted authority to actually do its job; the grading logic is in the certificate validity and certificate expiry methodology pages.

HTTPS is not the finish line: HSTS and downgrade attacks

Getting a valid certificate onto port 443 is necessary, but on its own it leaves one door ajar. The problem is the first connection. When you type example.com without a scheme, your browser tries http:// first out of habit, and only then follows a redirect to https://. For that brief moment the request is in cleartext — and an attacker positioned on the network can intercept it and prevent the upgrade from ever happening. This is a downgrade attack (the classic form is called SSL stripping): the victim believes they are on an ordinary site, the attacker quietly keeps the whole conversation on HTTP, and no certificate warning ever appears because HTTPS was never reached.

The fix is a single HTTP response header: HSTS, HTTP Strict Transport Security (RFC 6797). It tells the browser, in effect, “for the next N seconds, never speak to this domain over plain HTTP — go straight to HTTPS, and refuse to connect at all if the certificate is wrong.” Once a browser has seen a valid HSTS header, the vulnerable first-request window closes: even if the user types http://, the browser rewrites it to https:// locally before anything leaves the machine.

The census shows how far from universal this last step is. Of the domains serving evaluable HTTPS, only 20.1% — 46,539,716 — send an HSTS header. The other 79.9% leave the connection downgradeable, protected against passive eavesdropping but still exposed to an active attacker who can force the first request back onto HTTP. And the strongest form of the protection is rarer still: just 2.57% of HTTPS-evaluated domains are HSTS preload-ready, meaning hardcoded into browsers’ built-in preload lists so that even the very first visit, before any header has been seen, is forced onto HTTPS.

HSTS is the difference between “we support encryption” and “we require it.” It is a one-line header with a real deployment discipline behind it — you must be confident every subdomain can serve HTTPS before committing, because the header applies broadly and cannot be quickly undone in browsers that have cached it. The full picture, including the preload ladder and the migration risks, is in HSTS Adoption 2026: The Half-Locked Door and the companion explainer What Is HSTS? The Header 79.9% of Sites Still Skip. The grading criteria are in the HSTS header methodology.

How to check if your own site is properly on HTTPS

“Are we on HTTPS?” is really four questions, and a padlock in your own browser answers only the first. A proper check works down the list:

  1. Does the site serve HTTPS at all? Is there a certificate on port 443 that the browser accepts without a warning? For 44 million domains in the census, the answer is still no.
  2. Is the certificate valid and current? Not expired, not self-signed, issued by a trusted CA, and matching the exact hostname. A lapsed certificate breaks trust as thoroughly as having none — 5.2 million domains are serving expired ones right now.
  3. Does HTTP redirect to HTTPS? Type the bare http:// version. If it stays on HTTP instead of bouncing to https://, visitors following old links are served in cleartext. 27 million domains fail exactly this test.
  4. Is HSTS set? Is the connection protected against downgrade on the first request? Four out of five HTTPS sites still leave this open.

You can walk that list by hand, but the fastest route is a scanner that checks all four at once from the outside — the same vantage point an attacker or a receiving browser has.

Check your domain free at defaults.exposed — it reads your live TLS setup straight from the public internet and tells you whether you serve HTTPS, whether the certificate is valid and current, whether HTTP redirects to HTTPS, and whether HSTS is protecting the first connection. It takes about 30 seconds and needs no account. If the scan surfaces gaps and you want them closed properly — a valid certificate, a clean redirect, and HSTS done without breaking a single subdomain — see how the fix works.

What this means

For business owners, HTTPS is now the price of being taken seriously online. A visitor who sees “Not Secure” in the address bar, or a full-page certificate error, does not read the technical detail — they read “this company is careless” and leave, often before the page finishes loading. The census says 44 million domains are still in that position on encryption alone, before you even get to redirects and HSTS. The remedy is cheap: certificates are free and automatable, and the whole fix is a configuration task, not a rebuild. Staying on HTTP is not a saving; it is a slow leak of trust and traffic.

For IT and security teams, the certificate on port 443 is the beginning of the work, not the end. A serving certificate that is expired, self-signed, or mismatched fails the visitor exactly when they most need reassurance; a site that never redirects HTTP leaves a cleartext path standing next to the encrypted one; and a site without HSTS is one hostile network away from a silent downgrade. The census puts hard numbers on each of these — 5.2 million expired, 27 million never redirecting, 79.9% without HSTS — which is the difference between “we deployed TLS” and “we require it everywhere, on every request, including the first.”

FAQ

What does HTTPS mean? HTTPS means Hypertext Transfer Protocol Secure — ordinary HTTP web traffic carried inside an encrypted TLS connection. The “S” is not a separate protocol; it signals that a TLS session was negotiated before any web request was sent, giving the connection three properties: confidentiality (the traffic is encrypted so it cannot be read in transit), authentication (a certificate proves you are connected to the real hostname, not an impostor), and integrity (the data cannot be silently altered on the way). A URL starting https:// and shown without a browser warning means all three are in force. In the August 2026 census, 44 million domains still ran on plain HTTP with none of these protections.

How does HTTPS work? HTTPS works by running a TLS handshake before any page loads. The browser connects to the server on port 443, sends the TLS versions and ciphers it supports along with fresh public key material, and the server replies with its choice plus its certificate. Both sides use that key material to compute an identical secret without it ever crossing the network, and the browser validates the certificate against a trusted authority. Only once the encrypted channel is established does the real web request travel through it. Modern TLS 1.3 completes this in a single round trip, so HTTPS is fast to establish as well as private.

Is HTTPS the same as being secure? No — and conflating the two is a common and costly mistake. HTTPS secures the connection: it proves the traffic is encrypted and that you are genuinely talking to the hostname in the address bar. It says nothing about whether that hostname belongs to an honest business. Phishing and scam sites routinely use valid HTTPS certificates, which they can obtain free in minutes, precisely because the padlock lends them false credibility. HTTPS is a necessary foundation for trust, not a guarantee of it. You can confirm your own site’s TLS posture in about 30 seconds with a free check at defaults.exposed, but the padlock alone never certifies that a site is safe to trust.

Why does my browser say ‘Not Secure’? Because the page was loaded over plain HTTP with no encryption, or because its certificate failed validation. Modern browsers label every HTTP page “Not Secure” to make the absence of encryption visible, since anything you type on such a page — a password, a card number — travels in readable text that anyone on the network can capture. If a site does have a certificate but still shows a warning, the usual causes are an expired certificate (5.2 million domains serve one), a self-signed certificate no trusted authority vouches for (3.3 million), or a certificate that does not match the hostname. The fix is to serve a valid certificate and redirect all HTTP traffic to HTTPS.

Is HTTPS enough on its own, or do I need HSTS too? A valid certificate protects every connection that actually reaches HTTPS, but it leaves the first request exposed: if a visitor types the bare domain, the browser tries HTTP first, and an attacker on the network can trap it there before the redirect fires. HSTS closes that gap by instructing the browser to use HTTPS automatically and refuse HTTP entirely. Only 20.1% of HTTPS-serving domains set it, so four in five remain downgradeable. If you serve HTTPS, HSTS is the next step, not an optional extra — the details are in HSTS Adoption 2026.

Data to cite

See where your own domain stands

HTTPS is the one control every browser polices in public, in front of your visitors, with a “Not Secure” label or a full-page error. The census says 44 million domains are still on the wrong side of that line on encryption alone — and millions more serve a certificate but never redirect HTTP, or leave the first connection open to downgrade. Most owners have never seen their own posture stated plainly, because a padlock showed up somewhere and the check stopped there.

Check your domain free at defaults.exposed — it reads your live TLS certificate, redirect behaviour, and HSTS header straight from the public internet and tells you instantly whether your site is properly on HTTPS or only partly there. Takes 30 seconds. No account needed. If you want the gaps closed properly — valid certificate, clean HTTP-to-HTTPS redirect, and HSTS deployed without breaking a subdomain — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: The HTTP-Only Problem: 44 Million Domains Serving Unencrypted Web in 2026 · HTTP vs HTTPS: What’s the Difference, and Is HTTP Safe? · The Last Mile of HTTPS · What Is HSTS? The Header 79.9% of Sites Still Skip

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; 231,991,983 presented an evaluable TLS certificate. All figures are counts of scanned domains. References: RFC 8446 (TLS 1.3), RFC 5246 (TLS 1.2), RFC 6797 (HSTS), RFC 9110 (HTTP Semantics).

How to cite this report

Press / blog: defaults.exposed (2026). What Is HTTPS? How the Secure Web Actually Works. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-https-how-the-secure-web-actually-works

Academic: defaults.exposed. (2026, August 21). What Is HTTPS? How the Secure Web Actually Works. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-https-how-the-secure-web-actually-works

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 scanned domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026, of which 231,991,983 presented a TLS certificate that could be evaluated, using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →