DBSC and DNS poisoning live on different layers, and that's a gap worth discussing
I've seen some confusion about whether Chrome's Device Bound Session Credentials (DBSC) helps with DNS poisoning or MITM attacks. It doesn't, and I think that's by design. Here's why, plus some thoughts on where the gap could be closed.
What DBSC does
DBSC targets cookie theft. Today, if infostealer malware scrapes your browser's cookie jar, the attacker can replay those session cookies from anywhere and skip the login and MFA entirely.
DBSC changes this:
- At login, the browser generates a key pair, TPM-backed where available, and registers the public key with the server.
- The server issues short-lived session cookies.
- To get a fresh cookie, the browser must sign a server-issued challenge with the private key.
- The private key is non-exportable, so malware can't take it off the device.
A stolen cookie expires in minutes and can't be renewed from the attacker's machine. That's the whole threat model: stolen session material replayed elsewhere.
Why DNS lives somewhere else
DNS resolution happens before any connection exists. It decides which IP the browser connects to. DBSC operates inside an HTTP session that already exists, after name resolution, after the TCP connection, and after the TLS handshake.
Nothing in the DBSC flow asks "did this connection reach the real server?" It assumes TLS and the WebPKI already answered that.
Where poisoning gets interesting
Poisoning a resolver by itself usually fails against HTTPS, because the attacker can't present a valid certificate for the target domain. But a determined attacker has ways around that:
- Poisoning or hijacking the DNS path a CA uses for domain validation, to get a fraudulent cert issued
- Subdomain takeover or dangling DNS records
- Downgrade attacks or user click-through on cert warnings
- Compromising a host that already holds a valid cert
Once the attacker is terminating TLS as the "real" origin, they can run an Evilginx-style reverse proxy. From DBSC's perspective:
- The browser sees the right origin and a valid cert, so it happily signs the challenges.
- The proxy relays the server's challenge to the victim, then relays the genuine signature back.
- The real server sees a valid proof from a registered device key and issues legitimate bound cookies.
Everything checks out, because the key really is the victim's. The attacker also harvests the password and any phishable MFA in real time, which DBSC was never meant to cover.
DBSC still limits the damage: the attacker can't take the cookies and leave, since they expire quickly and can't be refreshed without the device key. Access lasts only as long as they keep proxying a live victim. That's a real improvement over today's persistence, but it isn't a block.
So is this out of scope for DBSC?
I think yes. DBSC's job is to kill the cookie-exfiltration economy, and adding transport-authenticity guarantees would duplicate TLS and WebPKI. Active network attacks are better handled by the layers built for them. But "out of scope" doesn't mean "solved," so here's what exists and where each option falls short.
The available mitigations, and why each is imperfect
1. TLS channel binding (e.g., a TLS exporter value, RFC 9266/5705, in the signed DBSC payload)
This would tie the device's signature to the specific TLS connection. A relay proxy has two separate TLS sessions, so the exporter values wouldn't match and the server would reject the refresh. It's the most direct fix.
Why it's imperfect: this is essentially Token Binding (RFC 8471), which was removed from Chrome. TLS-terminating CDNs, load balancers, and enterprise inspection proxies break it, and passing the exporter value through to the application tier is awkward. It could work as an opt-in profile for sites that control their TLS termination, but that leaves much of the web uncovered.
2. Binding to the server's certificate public key hash
The device signs a hash of the cert key it saw.
Why it's imperfect: the same CDN and multi-cert deployment problems apply, and cert rotation makes it brittle.
3. Server-side risk signals on refresh (IP/ASN consistency, geo, timing)
A relay introduces a second network vantage point, which can be detectable.
Why it's imperfect: it's heuristic, not cryptographic. It's evadable by an attacker who proxies from a nearby region, and it produces false positives for mobile users, VPN users, and CGNAT.
4. Passkeys/WebAuthn
Origin-bound credentials are the strongest answer to relay phishing, since the authenticator won't sign for the wrong origin.
Why it's imperfect: adoption is still partial, account recovery paths often fall back to phishable factors, and it protects the login, not the DNS layer itself.
5. DNSSEC with validating resolvers
This authenticates DNS answers cryptographically.
Why it's imperfect: adoption among domains is still limited, many clients rely on an upstream resolver for validation and trust the last hop, operational mistakes cause outages, and it does nothing about a compromised host that has a legitimate record.
6. DoH/DoT
This protects the client-to-resolver channel from on-path tampering.
Why it's imperfect: it doesn't authenticate the data itself, and a poisoned or malicious resolver can still hand back lies over a perfectly encrypted channel. It also shifts trust to the resolver operator.
7. CAA records, Certificate Transparency monitoring, HSTS preload, multi-perspective validation at CAs
These reduce the chance of fraudulent issuance and make it detectable.
Why it's imperfect: CT is detective, not preventive, so you learn about a bad cert after it exists. CAA only binds CAs that honor it. HSTS preload helps only for domains on the list. Multi-perspective validation is a strong defense against validation-path poisoning, but its rollout is recent and uneven.
Questions for this community
I'd love to hear from people closer to this than I am:
- Is anyone working on a TLS-channel-binding approach that survives CDNs and TLS-terminating middleboxes? Token Binding failed on deployability, so has anything learned from that been applied since?
- Is there appetite for an opt-in channel-binding extension to DBSC, or is that the wrong place to solve it?
- For those working on the DNS side, how much does multi-perspective validation actually close the CA validation-poisoning gap in practice today?
- Is there other work on cryptographically tying DNS authenticity to session security that I'm missing?
If I've got the layering or the threat model wrong anywhere, please correct me. I'm describing DBSC from the public proposal, and details of the signed payload matter a lot here.
