AI
How HTTP/2 Broadens the Definition of Origin
The same-origin policy restricts access by scheme, host, and port. HTTP/2 and HTTP/3 use a different rule: any host listed in a certificate’s Subject Alternative Name field shares an origin. Prior research at CCS found that
“shown that 96% of certificates contain multiple domains in their asen list” — Pinji Chen
and 3.2% of those certificates include domains from different organizations. Google’s wildcard certificate, for instance, covers android.com and youtube.com together. That SAN-based origin is more permissive than what browsers enforce at the URI level, and that gap is the foundation of both attacks.
The Cross-Push and Cross-SXG Attack Model
Both attacks require one precondition: the attacker holds a certificate whose SAN list includes the victim’s domain. With that in hand, an attacker on a completely separate network can serve a victim who visits the attacker’s site. HTTP/2 Server Push lets the attacker’s server deliver a response attributed to the victim’s origin via the authority pseudo-header. Signed HTTP Exchange (SXG) does the same via the request URL signature header. Either way, the browser accepts the response as coming from the victim’s domain. Prior work gave certificate holders man-in-the-middle capability only. These attacks work off-path.
What Attackers Can Execute via a Shared Certificate
Because the attacker controls the entire HTTP response, the attack surface is wide. JavaScript in the body produces XSS regardless of whether the target site has vulnerabilities or is even online. Content Security Policy cannot block it: the attacker simply omits the CSP header from the malicious response. A Set-Cookie header overwrites the victim’s session (the researchers showed the cookie change to “you hacked” in the cookie overwrite demo (09:01)). HSTS drops out by setting max-age to zero. A Content-Disposition header delivers a malicious file download (09:43) under the victim’s domain name.
Acquiring Shared Certificates and Extending Attack Duration
Two methods produce the shared-certificate precondition. Domain reselling: buy domains, issue a multi-domain cert, then sell the domains while keeping the cert. Domain takeover: a dangling DNS record pointing to a deprovisioned VPS or abandoned CDN lets an attacker register that service, pass HTTP validation, and issue a cert covering the hijacked domain. That cert stays dangerous for 398 days after the DNS fix, and domain validation reuse stretches it to 796 days by renewing on day 397. Victims cannot revoke it: Let’s Encrypt requires ownership proof for every SAN, and the victim cannot satisfy that for the attacker’s domains.
Scale of Exposure and a Real-World Microsoft Case
PS Checker, an automated tool the researchers built, found that 11 top browsers and 5 default mobile browsers accept at least one attack. Apps using mobile OS WebView inherit the same flaw, widening the target beyond browsers. On the server side, scanning the Tranco top 1 million found resold and dangling domains sharing certificates with high-ranked sites. A Windows Update subdomain’s CNAME pointed to an unregistered domain; the researchers registered it, issued a shared certificate, and ran the Microsoft XSS demo (21:36). Huawei, Baidu, and Microsoft are among five vendors that patched.
Notable Quotes
shown that 96% of certificates contain Pinji Chen · ▶ 2:54
expires which typically takes 398 days Pinji Chen · ▶ 13:07
Seven vendors confirmed the vulnerability and five vendors have Pinji Chen · ▶ 23:21
Key Takeaways
- HTTP/2 and HTTP/3 treat all domains on a shared certificate as same-origin, crossing organizational boundaries.
- Domain reselling and dangling DNS let attackers obtain shared certs; validation reuse extends attacks to 796 days.
- 11 top browsers and 5 mobile defaults are vulnerable; victims cannot revoke a certificate they don’t fully control.