> 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.
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.
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.
> 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.
"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%
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.
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
42 comments
[ 3.1 ms ] story [ 23.5 ms ] threadhttps://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?
Otherwise the attacker could just mint a non-EV cert, right?
EV certs went away because no user checked if the URL bar had the extra flair.
Hell:
AS: American Samoa
GH: Greenland
SL: Sierra Leone
I misread.
Thanks for the correction.
https://en.wikipedia.org/wiki/.gl
HPKP was deprecated because it was too dangerous to be deployed in production.
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.
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.
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.
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.
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%
Is it TLDs lacking support for this?
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