Certificate Authorities and the Fragility of Internet Safety | Hacker News Reader

Certificate Authorities and the Fragility of Internet Safety

azeemba.com

37 pointsLinuxBender31 comments

This whole thing is a little weird to me. It's prompted by the ICP-Brazil misissuance of Google certificates. I get that it's a big deal. And, if ICP-Brazil was generally in the root stores of Google, Mozilla, and Apple, I would agree that this is a real challenge to the integrity of the WebPKI.

But it's not. Microsoft is the only entity that trusts ICP-Brazil. Microsoft cut a deal with Brazil, exclusively regarding software Microsoft controls, to allow them to do... whatever it is they were doing.

You should be unhappy with Microsoft if you're a Microsoft customer. But this has almost nothing to do with the WebPKI. Microsoft could also have rigged their browser up to accomplish the same thing.

The ICP-Brazil thing was just a surprise coincidence as I was finishing up the article. I had started collecting my notes on the topic when Entrust got distrusted. Fun threads to read through:

- https://bugzilla.mozilla.org/show_bug.cgi?id=1890898

- https://groups.google.com/a/mozilla.org/g/dev-security-polic...

DigiCert incident was pretty loud so that got my attention too: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322

That's really stupid: they got in trouble for writing down a requirement that wasn't actually a requirement and wasn't meant to be a requirement, in a human readable document, and then not revoking and reissuing those certificates which didn't meet the requirement, which still don't meet it so revoking and reissuing achieves nothing, and weren't supposed to meet it anyway so there's nothing actually wrong with them. Part of the point of having humans in a process is so that they can make sensible decisions when the process prescribes something nonsensical, but Mozilla wants to follow the nonsensical process at all costs.

No that's not what they did. They had made promises about how they would handle issuing certs not in compliance with their CPS then went back on them, after a long history of similar things.

It's all brown M&Ms here.

"Hey, just so you know, we did read your brown M&Ms clause, but since last month M&M is running a special promotion where they only make rainbow colours, we got you a bowl of yellow ones instead."

Which is the correct course of action:

"Of course. Thank you for paying attention to the spirit of the rule."

Or: "No, fuck you, show is cancelled."

---

All of the stuff I said happened did happen. The extra context you are providing is irrelevant since it does not change the fact that what happened is stupid and it's Mozilla's fault that stupid stuff happened.

So the ICP Brazil thing is interesting.

It's not a certificate intended for use on the web in general. It's an open finance certificate designed for use within that ecosystem within Brazil, and it was issued to a google subsidiary who would have requested it to have that common name, and who would have been evaluated as being authorised to have such a certificate within that context.

The main problem seems to be that the root certificate was in the MS keystores, and seems to have previously been submitted to mozilla (and maybe others) for inclusion, which points to a poor separation of concerns for that CA. They clearly wanted to be a general web authority at some point, but were repurposed.

So it's hard to see it as purely a "misissuance", and it's definitely not malicious.

If I were interested in assembling an authoritative, up-to-date list of trusted CAs, would be reasonable to source lists from the major trust store providers and select only those CAs trusted by all of them? I know it's possible to be a lot more sophisticated and that even that can be flawed, but I'm hunting for a simple-to-follow criteria for now.

The CCADB tracks the various root programs, so you could do this today[1]. In practice however I think you’d be best off just using the Mozilla root program; I believe they’re as (if not more) strict than the corporate root programs in terms of inclusion.

[1]: https://www.ccadb.org/

Sounds like we need a certificate authority authority.

They exist: they're the Google and Mozilla root programs.

Bickering will just result in having multiple authorities.

This can be solved with a certificate authority authority authority.

The first will be named CARTMAN and must be respected by all.

I propose:

  public class CertificateAuthorityFactory{

I know this is an oversimplification, but if the main issue is the single point of failure (centralized trust), wouldn’t a potential solution be to layer independent verification mechanisms on top of the current system?

For example, a secondary DNS-based verification layer where a site’s public key is published as a DNS record (though that would likely need DNSSEC to be effective). It seems like it could complement the existing CA structure without replacing it entirely.

The problem with the CA system is arguably not that it’s a single point of failure: it’s that it’s N points of failure, all of which were originally unaccountable to user agents. The CAs are themselves decentralized entities, and each was largely unaccountable to the larger web PKI until CT came along.

I think a DNS layer would probably make that problem worse, not better, which is one of the enduring criticisms of DNSSEC and DANE.

You're likely right here, combining two trust systems does add complexity without solving the core problem. While browsers requiring CT was a great step forward, it's surprisingly under-utilized by orgs. I wonder if this is due to limited tooling for log interaction, or just general lack of awareness?

It's pretty widely used; orgs that have security teams with more than a handful of people tend to be monitoring CT for their own names. Could it be more usable? Yeah, there's probably more than one startup in there. Have at it! You don't need anybody's permission to build something like that.

> wouldn’t a potential solution be to layer independent verification mechanisms on top of the current system?

CT[1] allows some kind of external audit, but this is _mostly_ after the fact.

DNSSEC have much worse trust issue.

[1] https://certificate.transparency.dev/howctworks/

I kindly recommend to read certificate chain and how large scale companies are handle certificate provisioning. Those scenarios can happen if single CA is used and If you fully automated certificate generation aka domain private is generated by cloud provider and public key is signed with their intermediate certificate.

Moxie Marlinspike had a talk on exactly this issue many years ago now (maybe 2010-2012). Not much has changed since then

The WebPKI is drastically different than it was in 2012. Browsers all run their own root program. Certificate Transparency was not only launched (in 2013) but is now effectively mandatory for all CAs. Some of the largest CAs in the ecosystem were surveilled, had misissuance detected, and were put to death by the browsers. In 2010-2012, companies were still being sold CA:TRUE certs so they could intercept traffic on their own networks; now that would get your whole signing CA burnt.

It's OK not to pay any attention to the WebPKI! It's a whole specialized thing. But that's what you'd have to do to reach the conclusion that "not much has changed". The years following 2012 were the most momentous in the history of PKI.

> Browsers all run their own root program.

Do they?

I believe Firefox allows OS-level root CAs in addition to their built-in ones (not sure if that includes OS-provided ones or is limited to local administrator/user installed ones).

Chrome used to defer to the OS-provided one entirely, but it looks like it now has its own store and ignores OS-provided CAs (but does accept admin-provided ones).

Hm, the more I look at this... It seems like they do, these days :) At least the large ones; I doubt that smaller browsers such as Opera, Brave etc. have their own trusted root program.

Opera do. Cisco have their own. Oracle do (for Java, primarily) but tend not to participate in CA/B Forum much. Brave did previously have something of a root program - not sure if they still do or if they track Moz and/or Chromium. Quihoo 360 (China) have a root program, too. There are certainly other 'smaller' ones.

Interesting, although I do still suspect that the trend is to just piggy back onto one of the large well-respected ones.

For example, I do believe that Opera used to have their own (while they were still doing well), but they seem to be using Chrome these days [1]:

> Opera considers certificates presented trustworthy only when they either have a certificate chain that can be validated up to a Root CA certificate included in the Chrome Root Store or a certificate explicitly configured to be trusted by the user.

[1] https://security.opera.com/en/webpki-trust-anchors/

Certificate Transparency is pretty significant, arguably! It makes bad behavior much more transparent, at least.

Yeah, it really increases the cost of abusing the CA system, a lot.

Getting to a trustless decentralized name authority has shown to be elusive.

"trustless decentralized" is the last thing I want from my name authority.

When I enter some-entity.com, I want to know I'll end up at some-entity's website, even if said entity made some mistakes in the past, like forgetting to renew it [0]. I also want paypa1.com and friends to be down permanently, not to serve fishing pages.

[0] https://www.techdirt.com/2003/11/06/microsoft-forgets-to-ren...

Trusted third parties are security holes.

"Trusted third parties are security holes"

Indeed

True of the Great Financial Crisis too

Amen

Reply on news.ycombinator.com