Hackers obtain counterfeit TLS certificates for Google and other large services

From the Google blog "Chrome's Response to Recent ccTLD Registry Hijacks": "These incidents did not involve a compromise of Google’s systems; rather, attackers compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk. During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations." So entire top level domain registries were compromised. Interesting times. Isn't there really any primary source on this?

• proactivesvcs · 3 hours ago

  Other recent submissions include the link to google's blog at https://blog.google/security/chromes-response-to-recent-cctl... : https://news.ycombinator.com/item?id=49988253 https://news.ycombinator.com/item?id=49981886

• bsoqk · 2 hours ago

  Nothing novel about this. In fact this is the reason why years ago Google stopped using ccTLDs to serve their website.

• geocar · 21 minutes ago

  > These incidents did not involve a compromise of Google’s systems But a compromise of Google's users . I think we are potentially being told Google has domain names but no employees in those countries. This otherwise sounds quite implausible, and I don't know enough to say Google is lying.

  • knorker · 13 minutes ago

    > But a compromise of Google's users. Did it? If you get a link to google.gh, did you at any point assume that's the real Google?

The affected country ccTLDs are: AS: American Samoa GH: Greenland SL: Sierra Leone

• tyilo · 2 hours ago

  .gh is Ghana, not Greenland

This sounds like something that HPKP ( https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning ) could have prevented and CAA records ( https://letsencrypt.org/docs/caa/ ) could not. But HPKP is deprecated.

• w3ll_w3ll_w3ll · 1 hour ago

  CAA records (with ACME account bindings) can prevent this. HPKP was deprecated because it was too dangerous to be deployed in production.

  • iso1631 · 1 hour ago

    Not when you simply remove the CAA record from the DNS entry

    • w3ll_w3ll_w3ll · 44 minutes ago

      That is a good point.

    • geocar · 26 minutes ago

      You can't "simply" do that: a long cache period pins CAA. Of course that makes it the same, and with the same problems. What I'd like to see is the ability to use and utilise multiple TLS certificates and host keys on the same session so that all the keys could be rotated/phased in-band with cross-signing providing the authority. Seeing any mere change in the signers faster than (say) 30 days should allow the browser/client-stack to generate a warning that "google.com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma". No need to cross-publish the keys, just cross-sign and don't forget what you've seen previously. The browser would be able to take policy of simply never trust a certificate whose signer has changed (since phasing is possible), and it wouldn't then need to consult more public oracles (DNS, certificate transparency, etc, that leak privacy). I'd also like to get that webauthn hooked back into TLS client certificates: If we had 1997 again instead of passkeys that also would've stopped this.

      • mattashii · 19 minutes ago

        > The browser would be able to take policy of simply never trust a certificate whose signer has changed This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.

• airza · 1 hour ago

  The problem is that there is no out-of-band mechanism for update like other devices. If your CA certs are bad on your mobile application, you can push an out-of-band update via the device's app store. If your CA certs are bad on a website you access via your browser, the means of updating them is... the browser. You can't get new certs without using a TLS connection you didn't want to trust anyway.

• formerly_proven · 41 minutes ago

  Google Chrome has a static, preloaded pin set for Google's own web properties, I guess these minor ccTLDs were not covered by that.

• hdgvhicv · 41 minutes ago

  Only if someone had visited that site before, and it’s insanely risky and would damage far more sites than would save. The issuing was detected almost immediacy thanks to CT, and as we move to shorter certificate lifetimes the impact is continually reducing. The CAA record in dns is a weak link though.

  • GoblinSlayer · 29 minutes ago

    Visiting google damages you anyway.

  • knorker · 16 minutes ago

    Well, for Google specifically (and others who have opted in), this has been hard coded in some browsers before the first visit.

This seems like bullshit given certificate pinning and other countermeasures here. What am I missing ? Is it TLDs lacking support for this?

So looks like 1) Top level CC DNS entries were hacked 2) CAA entries were removed (I assume google had them -- they do now CAA 0 issue "pki.goog" 3) These were then used to verify issuing certificates against major CAs (letsencrypt etc) - for example by creating a new CNAME record for DNS verification Looking at google.as specifically shows Let's Encrypt issuing a certificate on 2026-09-27 https://ctlogs.dev/search?q=google.as Google normally issues certificates with "Google Trust Services", presumably their in house CA which all browsers trust, but the only way to limit issuing to Google is with the CAA record. If you hijack DNS, you hijack certificate issuing. As several CAs exist with no business relationship to identify the real person asking for the certificate, you can do this anonymously. (If CAs required verification then you'd just have to chain this with the stolen credentials of someone who uses that CA so wouldn't be a major obstacle) From what I can tell (and the article conflates this with the diginoir so implies it), this was NOT a compromise of a Certificate Authority

I'm just waiting for Claude-powered hackers to break into the dns root system or bgp routing system. It's going to be a wreck :(