SSL certificate blocking: how HTTPS gets filtered without being decrypted
Once the web moved to HTTPS, most of the old HTTP-based filtering stopped working. Regulators who wanted to keep blocking things had a choice: try to MITM everything (hard, and browsers fight back), or take advantage of the bits of the TLS handshake that are still readable on the wire. Most picked the second option, and that's what certificate blocking is — reading the cert the server sends, matching it against a list, and quietly killing the connection if it hits.
What it actually is
During the TLS handshake the server hands over its SSL certificate in plaintext — the handshake is encrypted later, but the cert itself travels in the clear long enough for anyone sitting on the wire to read the Common Name and Subject Alternative Names. A DPI box at the ISP does exactly that. If any of those names matches the blocklist, the box injects TCP RST packets and the connection dies before the application layer even starts.
What the wire sees
- 1. Client sends ClientHello
- 2. Server sends ServerHello + certificate
- 3. ISP DPI box reads CN and SAN fields from the cert (not encrypted yet)
- 4. Match against the blocklist
- 5. If hit — inject TCP RST to both client and server
- 6. User sees ERR_CONNECTION_RESET or a timeout with no explanation
The elegance, from the regulator's side, is that they never have to decrypt anything. It's all passive inspection of cleartext fields in a standard TLS 1.2 handshake. There's no forged certificate, no root CA to install, nothing for browsers to warn users about.
SNI filtering vs. certificate blocking
These are two closely related but genuinely different techniques, and the mitigations that work for one don't help with the other.
| SNI filtering | Certificate blocking | |
|---|---|---|
| Reads | ClientHello (from the browser) | ServerHello (from the server) |
| The data | SNI field | Certificate CN + SAN |
| When | Before the server has responded | After the server sends its cert |
| Defeated by ECH? | Yes — ECH encrypts the SNI | Not directly |
| Symptom | Refused / timeout | Reset mid-handshake |
Encrypted Client Hello (ECH) covers the SNI hole. That's one reason ECH adoption is making regulators nervous. TLS 1.3 also helps against certificate blocking specifically — the server cert is transmitted after the handshake is secure — which is why several countries actively interfere with TLS 1.3 negotiation on their networks, forcing a downgrade to 1.2 where the cert is still readable.
This isn't MITM
People hear "ISP inspecting my SSL" and assume full interception. That's a different thing. Certificate blocking and MITM differ in every meaningful way — what data is exposed, what the user sees, what equipment is needed.
Certificate blocking
- Passive — reads only what's already in the clear
- No decryption of anything
- No forged cert, no root CA
- Terminates the connection with TCP RST
- Nothing is intercepted or read
- User sees a generic connection error
True MITM / TLS interception
- Actively decrypts the traffic
- Presents a forged certificate to the client
- Requires a trusted root CA installed on the device
- Can read and modify everything
- Full data interception
- Browser warnings if the root CA isn't trusted
Kazakhstan is the often-cited cautionary tale here. They tried to roll out true MITM in 2019 by asking citizens to install a government root certificate, and Mozilla, Google and Apple all blocked that certificate within weeks. Everyone in the region has since moved to passive certificate inspection, which is much harder for browser vendors to do anything about.
Who actually does this
Certificate blocking requires decent DPI equipment and ongoing operational work, so it's concentrated in countries that have invested seriously in censorship infrastructure. The main ones we see in the wild:
- Russia: TSPU again. Widely deployed since 2019, runs across essentially all major ISPs, and certificate inspection is just one of its tools alongside DNS poisoning and SNI filtering. TSPU also interferes with TLS 1.3 negotiation on some networks to keep certs visible.
- Kazakhstan: After the national root CA plan got shut down, Kazakhstan moved to passive inspection. Less comprehensive than Russia's setup but effective for the specific domains it targets.
- Uzbekistan: DPI capable of cert inspection, used mostly against gambling and political content. Enforcement is uneven between ISPs, but the capability is definitely there.
- Other CIS: Belarus, Turkmenistan and Tajikistan have various flavors of this, mostly using Russian-provided or Russian-style equipment.
What HTTPS-only sites experience
Almost every serious site is HTTPS-only at this point, which means there's no plain-HTTP fallback. When certificate blocking fires, the connection just doesn't work — there's nothing else to try.
- • No block page. Unlike DNS poisoning, there's no warning page. The user sees a generic browser error and usually thinks the site is down.
- • Intermittent-looking. DPI under load doesn't inspect every connection. So the site "mostly doesn't work but sometimes does", which is the worst possible support ticket.
- • Hard to diagnose. Technical teams will chase server and network issues for days before anyone suggests the word "block".
- • CDNs don't help. Cloudflare's shared cert carries your SAN, which means the DPI box flags the Cloudflare cert the same way it flags yours. Putting a CDN in front of the origin does not fix this.
How we detect it
Catching certificate blocking needs a different approach than DNS or HTTP detection, because the failure mode is so quiet. A few of the techniques we use:
- 1Full TLS handshake from real ISP networks
We initiate the handshake and actually observe what happens. DNS resolves fine, TCP connects fine, ClientHello goes out, ServerHello comes back, and then — TCP RST. That timing signature is the thing to recognize.
- 2Looking at when the reset arrives
A reset right after ServerHello, from a specific ISP network, that doesn't reproduce from a different ISP in the same country — that's certificate or SNI blocking, and it's distinguishable from server-side issues or ordinary connection noise.
- 3Cross-ISP comparison
A block that only exists on one operator but not others points at an ISP-specific filter rather than a server problem. This is the sanity check that separates real blocks from flaky networks.
- 4Certificate fingerprinting
We keep a fingerprint of the cert we expect to see for your domain. If the cert that arrives at the check point is different, something is replacing it on the way — rare but worth knowing about.
- 5Protocol downgrade detection
Some DPI systems force TLS 1.3 down to 1.2 so that certificates stay visible. We track which networks are doing this, which is a secondary but useful signal.
Certificate-based blocking is one of the blocking styles that most generic uptime monitors just cannot see. If you're running checks from AWS Frankfurt, you will get a clean 200 OK forever while your users in Almaty can't load the site. This is specifically the gap we're trying to close — the checks run from residential networks and the detection logic knows what to look for.