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.
dingaling 3 hours ago [-]
"as we move to shorter certificate lifetimes the impact is continually reducing"
When a company has 3 billion customers, there's no practical cert lifetime that really reduces exposure. Five minutes would sniff enough traffic to do significant damage; one day would impact a big chunk of their users and five days would be nearly 100%
silenc3d_sage 2 hours ago [-]
Am I wrong in thinking that removing this attack surface entirely would eliminate that ability to offload to CDNs?
GoblinSlayer 9 hours ago [-]
Visiting google damages you anyway.
sylware 7 hours ago [-]
+1
ajross 6 hours ago [-]
> The issuing was detected almost immediacy thanks to CT
Which means that the risk to you or I or the general public is low.
But FWIW: it also tends to argue that this is the aftermath of a coordinated, targeted attack against a single high value target (or at most a small set of targets they could hit within the window). The attacker knew they had a gun with only one bullet, and we're just hearing the muzzle report.
rithdmc 5 hours ago [-]
Certificate Transparency logs are from late September, and public reporting is from October 6. I wonder how wide or narrow that window truly was?
Edit: Someone more curious than I am might be able to answer this by seeing when the CRLSet was published. https://github.com/agl/crlset-tools
knorker 9 hours ago [-]
Well, for Google specifically (and others who have opted in), this has been hard coded in some browsers before the first visit.
hdgvhicv 8 hours ago [-]
Solutions for Google and instagram and whatever are trivial.
General solutions are tricker, and it’s good that Google limits its “special” case. When bbc.com or al jazzera or cnbc or whatever is hacked that’s a problem that is only solved by generic solutions.
knorker 6 hours ago [-]
Hence why I said "for Google specifically".
w3ll_w3ll_w3ll 10 hours ago [-]
CAA records (with ACME account bindings) can prevent this.
HPKP was deprecated because it was too dangerous to be deployed in production.
iso1631 10 hours ago [-]
Not when you simply remove the CAA record from the DNS entry
geocar 9 hours 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 9 hours 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.
geocar 4 hours ago [-]
I think you are very likely to use the same signer if you actually lose the key, so this isn’t something I think a naive sysadmin is going to fuck up the way they fuck up host pinning.
mattashii 3 hours ago [-]
How can you use the same signer when the signer's keys are lost?
Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised, you have to re-issue all certs. When the client pins the CA key then the chain of trust is permanently broken.
geocar 2 hours ago [-]
> How can you use the same signer when the signer's keys are lost?
You mean, hypothetically if Letsencrypt suddenly loses the ability to sign new requests from me?
Well, then I have around 30 days to detect that and choose a new signer.
> Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
Again, to be clear, you're talking about Letsencrypt's own signing keys in this case, being compromised and them being denied access to them. That seems incredibly unlikely to have both failures at the same time, but again: I have 30 days to find a new signer.
> The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised
No! In fact, if Letsencrypt sublicenses signing to a third-party that certificate would be considered separate and so the switcheroo would be detected!
> When the client pins the CA key then the chain of trust is permanently broken
That's why it is important to extend TLS to allow multiple keypairs and certificates to be used to mutually authenticate the session key, so that any of the previous pinned keys can be used to update the pin. I did not say I wanted this for no reason!
iso1631 4 hours ago [-]
Well google.as has a CAA record of 24 hours now. I assume it had one before.
Therefore either
1) Letsencrypt ignore CAA records (unlikely)
2) The DNS hijackers removed the CAA record 12+ hours before doing their attack and google did not notice (I'd hope unlikely)
3) Letsencrypt querys did not return a cached CAA record because their resolvers had not been asked for it, so removing the CAA record a few minutes before hand worked.
> .com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma
Do you seriously think this is an appropriate message to give to Aunt Irene?
9 hours ago [-]
w3ll_w3ll_w3ll 9 hours ago [-]
That is a good point.
airza 10 hours 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 9 hours 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.
iso1631 10 hours ago [-]
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
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
"Web PKI" depends on DNS, specifically "domain names"
chrisjj 7 hours ago [-]
Increasingly it seems domain cert issuance is too important to be left to computers. Shame we have no backup solution.
13 hours ago [-]
fulafel 13 hours ago [-]
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?
> 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 9 hours 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?
proactivesvcs 8 hours ago [-]
If I received a link to google.co.uk I would, because I'm in the UK. Why would I think otherwise if I were in Ghana and saw a link to google.gh?
phicoh 7 hours ago [-]
Browsers happily killed EV certificates. With EV such a hack would take quite a bit more effort.
knorker 6 hours ago [-]
I have a machine in the UK. If I use it to go to google.co.uk, it redirects to google.com.
Hell:
$ curl www.google.es
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
aiXis 12 hours ago [-]
[flagged]
netik 12 hours ago [-]
This seems like bullshit given certificate pinning and other countermeasures here. What am I missing ?
Is it TLDs lacking support for this?
preisschild 6 hours ago [-]
certificate pinning is generally not recommended and wouldn't work in browsers that use the browsers/operating system's root CA store anyways. CAAs can be edited by the one who controls the domain's DNS records.
caniload 11 hours ago [-]
[flagged]
TheChaplain 9 hours ago [-]
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 :(
podocarp 8 hours ago [-]
Time to set up our own nets with portable radios
mitxela 8 hours ago [-]
A central authority can give each of us a chunk of a 128-bit address space and then we can route peer to peer based on shortest paths. Wait...
Did you know you're allowed to own an IP address block without making it publicly routable? They will have to periodically call you to make sure you're still using it, but it's otherwise allowed.
foobarian 6 hours ago [-]
How much does a /24 go for these days anyway...
preisschild 6 hours ago [-]
Thats hardened infra, not vibe coded webapps. There are a lot fewer vulnerabilities in that.
mitxela 8 hours ago [-]
BGP hijacking occurs periodically but not with Claude
bakugo 8 hours ago [-]
Can we please have just one post on the front page of HN without AI astroturfing comments at the top?
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.
When a company has 3 billion customers, there's no practical cert lifetime that really reduces exposure. Five minutes would sniff enough traffic to do significant damage; one day would impact a big chunk of their users and five days would be nearly 100%
Which means that the risk to you or I or the general public is low.
But FWIW: it also tends to argue that this is the aftermath of a coordinated, targeted attack against a single high value target (or at most a small set of targets they could hit within the window). The attacker knew they had a gun with only one bullet, and we're just hearing the muzzle report.
Edit: Someone more curious than I am might be able to answer this by seeing when the CRLSet was published. https://github.com/agl/crlset-tools
General solutions are tricker, and it’s good that Google limits its “special” case. When bbc.com or al jazzera or cnbc or whatever is hacked that’s a problem that is only solved by generic solutions.
HPKP was deprecated because it was too dangerous to be deployed in production.
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.
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.
Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised, you have to re-issue all certs. When the client pins the CA key then the chain of trust is permanently broken.
You mean, hypothetically if Letsencrypt suddenly loses the ability to sign new requests from me?
Well, then I have around 30 days to detect that and choose a new signer.
> Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
Again, to be clear, you're talking about Letsencrypt's own signing keys in this case, being compromised and them being denied access to them. That seems incredibly unlikely to have both failures at the same time, but again: I have 30 days to find a new signer.
> The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised
No! In fact, if Letsencrypt sublicenses signing to a third-party that certificate would be considered separate and so the switcheroo would be detected!
> When the client pins the CA key then the chain of trust is permanently broken
That's why it is important to extend TLS to allow multiple keypairs and certificates to be used to mutually authenticate the session key, so that any of the previous pinned keys can be used to update the pin. I did not say I wanted this for no reason!
Therefore either
1) Letsencrypt ignore CAA records (unlikely)
2) The DNS hijackers removed the CAA record 12+ hours before doing their attack and google did not notice (I'd hope unlikely)
3) Letsencrypt querys did not return a cached CAA record because their resolvers had not been asked for it, so removing the CAA record a few minutes before hand worked.
> .com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma
Do you seriously think this is an appropriate message to give to Aunt Irene?
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.
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
AS: American Samoa
GH: Greenland
SL: Sierra Leone
I misread.
Thanks for the correction.
https://en.wikipedia.org/wiki/.gl
"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?
https://news.ycombinator.com/item?id=49988253
https://news.ycombinator.com/item?id=49981886
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.
Did it? If you get a link to google.gh, did you at any point assume that's the real Google?
Hell:
Is it TLDs lacking support for this?
Did you know you're allowed to own an IP address block without making it publicly routable? They will have to periodically call you to make sure you're still using it, but it's otherwise allowed.