What is HTTPS filtering

Most of the modern web rides on HTTPS, including the ad networks, trackers, and fingerprinting scripts that we exist to block. This page explains, in plain language, why Adblock needs to look inside HTTPS traffic to do its job, how that works under the hood, and what we do to keep your connection safe while it happens.

A quick refresher: HTTP vs. HTTPS

HTTP is the protocol your browser uses to talk to web servers. On its own, it is unencrypted — anyone sitting between you and the server (your ISP, the coffee‑shop Wi‑Fi, a curious roommate on the same network) can read or modify what is being sent.

HTTPS is the same protocol with a TLS layer wrapped around it. TLS does two things at once:

Encrypts the data so eavesdroppers see only ciphertext.
Authenticates the server so you know you are actually talking to bank.example.com and not an impostor.

Today HTTPS is the default. Browsers warn loudly on plain HTTP, search engines deprioritize it, and free certificate authorities like Let's Encrypt have made it practically the table‑stakes setup for any site.

What a TLS certificate actually does

A TLS certificate is a small signed document that says: "the public key inside this certificate belongs to this domain". It is signed by a Certificate Authority (CA) that your operating system or browser already trusts.

When your browser opens an HTTPS connection it:

Receives the server's certificate.
Checks that it was signed by a trusted CA, that it has not expired, and that the domain on the certificate matches the site you asked for.
Uses the public key inside the certificate to negotiate an encryption key with the server.

If any of those steps fail, the browser refuses to load the page. That is the mechanism that keeps HTTPS trustworthy.

Why Adblock needs to filter HTTPS

If we could only see plain HTTP, we would be useless on the modern web. The sites where ad blocking matters most — large video platforms, social networks, news outlets, search engines — all serve their pages, their ads, and their trackers exclusively over HTTPS. To remove an ad request, we have to be able to see that the request is being made.

Concretely, HTTPS filtering is what lets Adblock:

Block tracker and ad requests at the network layer instead of relying solely on the browser.
Filter ads inside apps that do not use a browser engine at all (many native Windows apps embed their own HTTP clients).
Apply the same rules system‑wide, so protections do not stop the moment you switch browsers or open a third‑party app.

How HTTPS filtering works in Adblock

HTTPS is designed to make it hard for anyone to insert themselves between you and a server. To filter it, Adblock has to act as a consensual middle layer that you have explicitly trusted on this device.

When a connection is filtered, Adblock builds two TLS sessions back‑to‑back:

Adblock ↔ the remote server. Adblock opens a normal TLS connection to the website, validates its certificate exactly the way a browser would, and refuses the connection if anything looks wrong.
Your browser/app ↔ Adblock. Adblock then presents a certificate of its own to the local app. That certificate is signed by a private root certificate that Adblock generated on this machine, just for this installation, and that we registered with the Windows certificate store during setup.

Because your apps trust that local root, they accept Adblock's certificate the same way they accept any other. Adblock can now see the request, run it through the filter rules, and forward it to the server (or drop it). The response gets the same treatment on the way back.

The net effect: your app talks to Adblock over TLS, Adblock talks to the server over TLS, and ad/tracker traffic gets blocked in between. Plain unencrypted data is never exposed to the network.

"Is my data still private?"

Yes — with two important nuances that we want to be upfront about.

The connection to the server stays encrypted. Adblock validates the real server certificate (expiration, hostname, signing chain, revocation hints) just as a browser would, and aborts on anything suspicious. Your traffic never touches our servers; everything happens locally on your PC.

The certificate your browser sees is the local Adblock one, not the site's original certificate. That is unavoidable for any product that filters TLS, and it is the main trade‑off of HTTPS filtering. Two consequences worth knowing:

Browser features that depend on inspecting the original certificate (for example the EV "company name" indicator, or certificate‑pinned sites) do not see the original chain while filtering is on.
The local root key lives only on your machine, in protected OS storage. We never transmit it, and a fresh one is generated for every install — there is no shared secret across users.

Sites we never filter by default

Some traffic should not be touched no matter how well‑behaved the filter is: banking, payments, health portals, government services, and similarly sensitive sites. Adblock ships with a maintained allowlist of these domains and skips HTTPS filtering on them entirely. They simply tunnel through unmodified, with the original certificate going straight to your browser.

If you spot a site you believe should be on that list, let us know and we will review it.

Extended Validation (EV) certificates

EV certificates require extra paperwork and identity verification before a CA will issue them. They are most often used by banks and large e‑commerce sites. Adblock can be configured to skip filtering for any site that presents an EV certificate, in which case the original chain is preserved end‑to‑end and your browser shows the EV indicator as usual.

Known trade‑offs

Filtering TLS is a powerful tool, and we treat it as such. A few honest limitations:

Certificate‑pinned apps. Some apps ship with a hard‑coded list of certificates they will accept. Those apps will reject Adblock's certificate by design. Filtering is automatically skipped for known pinned services so they keep working; for anything else, the app's own connection is left alone.
HSTS / Expect‑CT signals. Because Adblock terminates TLS locally, some transport‑security signals (HPKP, certain Expect‑CT modes) cannot be enforced end‑to‑end. We compensate by validating the upstream certificate ourselves and refusing to forward connections that fail.
The local root is only as safe as the OS keystore. That is why Adblock installs the root into the protected Windows certificate store rather than carrying its own trust file, and why removing Adblock cleanly removes the root with it.

We continue to invest in the certificate validation library that backs all of this, and we publish details of any meaningful changes to the way HTTPS filtering works.

Verifying your connection quality

If you want to confirm that filtering is not weakening your TLS, the same public test sites used for browsers will work for Adblock too:

Run them with filtering on and off and compare. Modern cipher suites, certificate validation on broken test endpoints, and protocol downgrade resistance should all behave the same way they do without Adblock in the loop.

TL;DR

The web is encrypted now, and so are most ads and trackers.
To block them, Adblock has to participate in the TLS handshake — with your consent, using a root certificate generated locally on your machine.
Your traffic stays encrypted on the wire. The certificate your browser sees is Adblock's local one; the connection to the actual server is validated the same way a browser validates it.
Sensitive sites (banking, health, government, EV‑certified) are excluded from filtering by default.
You can verify all of this yourself with public TLS test sites.