Thread

Building a certificate authority for the whole Internet

65 points · 51 comments · ewpratten

Loading the complete thread in the background. This saved snapshot is available now. Refresh

MisterMunchkin · 1790692637 · focus · HN ↗
It makes sense for them to issue their own certificates because it’s inline with the rest of their offerings, but it seems kind of strange you can just buy someone else’s root certificate and issue under their name. It kind of defeats the point of trusting the root. What if a bad actor starting buying up authorities? You could compromise a bunch of services without them even knowing.
1. phillipseamore · 1790703656 · focus · HN ↗
  Not a huge difference between buying the root cert itself and getting a cross-sign. LE started out with cross-signs from Identrust.
  "On October 19, 2015, the intermediate certificates became cross-signed by IdenTrust, causing all certificates issued by Let's Encrypt to be trusted by all major browsers."
2. evan_a_a · 1790708646 · focus · HN ↗
  There are a whole host of controls in place to mitigate this risk. Plus such an acquisition wouldn't be easy to keep secret, so as soon as an untrusted actor acquired control over a root, the CAB would likely immediately distrust the cert.
  <a href="https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.5.pdf" rel="nofollow">https://cabforum.org/working-groups/server/baseline-requirem...
  1. vg · 1790740669 · focus · HN ↗
    CAB has nothing to do with trust/distrust here. Its the Root CA Store Operators (Mozilla, Google, Apple, Microsoft, Adobe) which have to distrust here.
    crote · 1790762578 · focus · HN ↗
    In other words: the CAB members would distrust the CA because the CA would be in violation of their individual root store policies, specifically the "you must follow the rules set by the CAB" part.
3. vg · 1790740559 · focus · HN ↗
  Google (GTS) has done the same. GTS controls GlobalSign R4. GlobalSign R4 was a root cert which was created by GlobalSign and later sold to Google.
  If a bad actor starts buying up CA's, then very quickly that CA would be distrusted by Root Cert Store Operators. No different than what happened with DigiNotr and Entrust.
4. Tomte · 1790744741 · focus · HN ↗
  It is, but that‘s why I trust Honest Achmed (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=647959" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=647959). He is a man of integrity and will not be bought!
phillipseamore · 1790703805 · focus · HN ↗
Would like to see them working more with TLD operators here, I'd like to see a CA partner with TLD ops to offer distributed and resilient issuance (especially with shorter cert lifetimes) with intermediate certificates locked to their TLDs, TLD operators are already a significant part of the chain of trust since it's all based on DNS today.
1. vg · 1790740344 · focus · HN ↗
  What you are proposing sounds like DANE with TLSA and DNSSec. Great idea but most CC TLDs are still using 1024 RSA ZSKs. Right now PQ DNSSEC is very uncertain. PQ DNSSEC will likely take about 5 more years or so to standardise. And thats too late for companies like Google and Cloudlfare which want to go PQ Crypto by 2029.
  1. phillipseamore · 1790758595 · focus · HN ↗
    No, I'm proposing that TLD can handle issuance themselves since they technically have 100% control over domains under their TLDs anyways. I think this might be important when we look at a combination of short (and getting shorter) lifetimes for end-user certificates and increasing volatility of the world (cyberattacks, sabotage and war). It would be desirable for ccTLD's specifically to be able to maintain certificate issuance even though the country was virtually or physically isolated from the rest of the world. (Which DANTE could/would have mitigated but is not my proposal here)
    sneak · 1790773506 · focus · HN ↗
    It's almost like they could put their CA's public key into the dns, and the sub-zones could carry signatures over their own keys, to make dns secure. you could call it something like "dnssecure".
m4rtink · 1790708103 · focus · HN ↗
Totally not a single point of failure for the whole Internet.
m463 · 1790709776 · focus · HN ↗
Just say no. Cloudflare should not be the gatekeeper for the internet.
1. quinnjh · 1790728869 · focus · HN ↗
  Who do you like to go with for certs?
  1. N_Lens · 1790738139 · focus · HN ↗
    I personally recommend Voldemort. His snakelike demeanour and disregard for human life impresses me with a sense of ominous authority!
  2. ricudis · 1790762599 · focus · HN ↗
    Honest Achmed, of course!
2. sneak · 1790773836 · focus · HN ↗
  They're not. You're free to run and visit websites that don't use CF, and you're free to get certs from non-CF CAs. What on Earth makes you think that they are any sort of gatekeeper of the web?
  1. fragmede · 1790774215 · focus · HN ↗
    The fact that an increasing percentage of the web uses them for interdiction.
    kdkcienciencjs · 1790781633 · focus · HN ↗
    By choice. There’s absolutely nothing keeping you from using other providers and not using CloudFlare does not block you in any way.
    fragmede · 1790781840 · focus · HN ↗
    Not using Cloudflare means I can't access a site that I don't run that has chosen to use Cloudflare. I can choose not to use that site, but my life will be lessened for that, so not using Cloudflare blocks me in that way.
    stubish · 1790825376 · focus · HN ↗
    Yes, that sort of boycott requires sacrifice, choosing to not deal with people who have different opinions. Its why mostly people might boycott meat but not people who eat meat.
    sneak · 1790826220 · focus · HN ↗
    The site operator gets to choose who they serve to, and they choose not to serve to people who don’t want their traffic proxied through Cloudflare. That’s not Cloudflare gatekeeping, that’s a decision by the site operator.
    fragmede · 1790826936 · focus · HN ↗
    And in a world where the site operator is perfectly spherical, with unlimited free time and budget, you'd have a point.
    > What on Earth makes you think that they are any sort of gatekeeper of the web?
    Unfortunately, site operators have to operate on the Internet we actually have, full of DDoS attacks and wanton scrapers, so a sufficient number of site operators have chosen to use Cloudflare, so as to reduce their burden, so in isolation, yeah, sure, the problem is that in aggregate, they do have keys to the gate of sufficiently large swaths of the Internet, that they are de facto gatekeepers of that particular portion of the Internet. If you are privileged enough to be able to opt out of that portion of the Internet, count yourself lucky!
bossyTeacher · 1790712258 · focus · HN ↗
The internet was meant to be a decentralized network. Why are humans so narrow minded short-termists?
1. thephyber · 1790727988 · focus · HN ↗
  Why does every criticism of CloudFlare ignore the fact that they mitigate the largest DDoSes in the world in an age where DDoS-for-hire cost only a few dollars per minute? Nobody could do that on the budget of a 1996 local ISP with one or 2 part-time IT techs.
  CloudFlare was launched as a stupid-simple CDN, but DDoS mitigation and bot reduction are actually valuable features for many websites. Sure, CF isn't the only business in this space, but most of their rivals are large enough to be in the S&P500 / Russell 2000, so it's not like garage startups are competing for this business.
  "Was meant to be"
  This isn't a law of physics. This was a starry-eyed hope by techno-utopians and academics when the internet was still 100% funded by Uncle Sam. When the internet moved out of its parents' basement, it had to grow up and get a job to pay the bills. Some people are fine with a SquareSpace webpage instead of running their own custom Apache httpd website on bare metal in a colo like it's 2005. The cost of maintenance and cognitive load is a cost we shouldn't ignore.
  It turns out that economies of scale exist. The Internet doesn't need 10,000 small CDNs and they would all be inefficient and expensive if that was the distribution. Instead, there are a few large ones that can afford to colo in many geographically dispersed data centers and who negotiated bandwidth peering contracts for advantageous pricing.
  1. bhhaskin · 1790731133 · focus · HN ↗
    Except they protect the same people running DDoS services...
    LoganDark · 1790733178 · focus · HN ↗
    No they did, but they changed their mind once people spoke out against it. They thought free speech absolutism would be good for PR, but it turns out that the general public hates bad people enough not to care.
    RVuRnvbM2e · 1790738071 · focus · HN ↗
    This is BS. One quick google and selecting a result from the first page: <a href="https://zeusstress.com/" rel="nofollow">https://zeusstress.com/
    Surprise! It's on crimeflare.
    LoganDark · 1790748710 · focus · HN ↗
    KiwiFarms, 8chan, The Daily Stormer all got removed for public backlash... didn't know there were others still on Cloudflare. Thanks.
  2. jart · 1790743458 · focus · HN ↗
    [delayed]
    [deleted] · 1791066420 · focus · HN ↗
    [deleted]
  3. nottorp · 1790754304 · focus · HN ↗
    ... because some people can think long term ...
  4. edelbitter · 1790764751 · focus · HN ↗
    [delayed]
2. stubish · 1790734027 · focus · HN ↗
  Capitalism, starting the moment TLD registrars first bid for the monopoly to charge rent. And continuing today, where I think only Cloudflare offer below or at cost domain registration, charging nothing themselves and just passing on the other mandatory fees to the rent seekers. It has had centralization at its heart since the beginning, when someone had to allocate IP addresses and everyone else had to agree (or we would have internets and not The Internet), which enabled this. I wonder if it would have turned out differently if, instead of central IP address allocation, clients had generated a UUID and it was accepted on The Internet unless consensus agreed it wasn't unique? But I don't think we knew how to do that then and technical limitations. Heck, crypto export laws would have killed it and required a central authority to prove that a UUID was you and not an imposter.
3. N_Lens · 1790738022 · focus · HN ↗
  Evolution & the illusion of the separate self.
4. supertrope · 1790738704 · focus · HN ↗
  Key signing parties don’t scale.
5. zoobab · 1790772814 · focus · HN ↗
  Because some people want power, and abuse it.
6. aseipp · 1790773619 · focus · HN ↗
  You could also make the alternative argument: the internet as a truly decentralized network as imagined by nerds was never going to actually work due to its (now obvious) impact on the political economy of the world and its actors, and because fundamentally centralized economies of scale are how humans tend to organize society. So why are internet nerds on forums so narrow minded, they don't read books or understand this?
7. sneak · 1790773735 · focus · HN ↗
  The internet was never meant to be decentralized. It was a project researched and started by centralized entities (DOD, ARPA) that wanted to maintain command and control authority for a single person (POTUS) in the event of a physical catastrophe.
  It was meant to be resilient and have multipath capability to route around damage. Having command authority sourced from multiple places was never part of the goal, and, indeed, in the client/server model that has prevailed the entire time the internet has existed, nothing about the design of the internet has been explicitly created to allow for server or data redundancy or distribution.
  decentralized != distributed
  Indeed, on the "modern internet" (aka the last 25+ years), everyone uses NAT, which means that end to end connectivity is not needed or wanted by most users and engineers. This idea that "every host should have a public IP, and every host should be a server as well as a client" is just fantasy that has no basis in reality, either in intent, or in practice.
  1. fragmede · 1790774873 · focus · HN ↗
    IPv6 isn't a fantasy though. True, it hasn't worked out as hoped, but regardless of original intentions, IPv6 does let each client also be a host.
ggm · 1790727574 · focus · HN ↗
[dead]
LoganDark · 1790733045 · focus · HN ↗
As always, I am worried to see Cloudflare and Google Chrome -- two of the internet's biggest/worst monopolies -- working so closely together like this. Cloudflare is already undergoing enshittification, like banning all automation by default that hasn't undergone privacy-invasive certification procedures (they recently started calling disallowed bots "AI Training", but that doesn't change anything -- you still have to be on a whitelist in order to be allowed). I have no doubt that in the near future, they will release some kind of ID verification and then the vast majority of the internet is simply done.
1. stubish · 1790734306 · focus · HN ↗
  A bot owners enshittification is a site admins salvation. The toggle is trivial to turn on or off. What will site admins do I wonder?
  1. LoganDark · 1790735543 · focus · HN ↗
    That's not my point. Cloudflare is blocking all unregistered automation as "AI Training" by default. My guess is we will see almost no one changing that default, as opposed to the inverse where only some sites will be forced to enable the blocks. Opt-out is a very bad model for things like this because it heavily hurts users (especially assistive users) while most websites won't have a strong enough opinion to even consider it.
    I don't think we will see Cloudflare enabling an "age assurance" requirement by default. I feel like I could trust them slightly more than a site operator, depending on how it's performed, but I also feel like it would be very easy for them to do much, much worse than any site operator, due to the inherent power of being a GAA. (Global Active Adversary, to those not familiar)
    stubish · 1790761730 · focus · HN ↗
    I think it is the point. Bots have become the enemy. Most websites will have a strong opinion first time they look at the weblogs and realize how much of their capacity and money is being used for... something other than what they wanted it to be used for. Bots are no longer a rounding error. And yes, there are certainly innocent victims in the roadkill.
    sneak · 1790773871 · focus · HN ↗
    It's the server operator's choice what sort of clients they wish to serve, and how.
    LoganDark · 1790782439 · focus · HN ↗
    Exactly, Cloudflare should not be blocking bots for everyone by default, they should leave it up to the operators!!
    sneak · 1790939154 · focus · HN ↗
    The server operators chose Cloudflare and Cloudflare’s defaults.
    LoganDark · 1791204119 · focus · HN ↗
    I do not support this argument at all. Just because I choose Cloudflare does not mean I choose that default. It doesn't even mean I choose the existing defaults. I'm getting tired of people saying you could've/should've just chosen something else -- that would change everything, not only the things you have problems with.
    It's the same issue I have with laptops that aren't MacBooks -- you cannot just fix an issue with a MacBook by choosing something else. That something else lacks everything good about the MacBook and you'll have even more problems.
    Also, not everyone has implicit trust in everyone else's future direction. No outsider could have known they would do this! The only reason you could've chosen them for it is if you already agree with this default. It's entirely fair to push back against defaults you disagree with. Especially when stuff like this suddenly makes a majority of the internet way worse for users.
ericpauley · 1790734224 · focus · HN ↗
Interesting, but the article would be far more enjoyable to read if it weren’t clearly written by Claude.
abofh · 1790737988 · focus · HN ↗
Me too, just add my root and you'll never be warned again!
You have access to unlimited free certificates based on DNS delegation through this method, but need more.
It might be useful to explain why this adds value that another CA can't
1. vg · 1790755404 · focus · HN ↗
  Are you as honest as Honest Achmed? (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=647959" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=647959)
vg · 1790740135 · focus · HN ↗
A very welcome move because for years Cloudflare has freeloaded certs from Let's Encrypt without sponsoring Let's Encrypt finacially. Though Cloudflare has contributed in otherwise to the ecosystem like by running CT logs etc.
Now, it looks like WebPKI is going to fracture into two regarding PQ Crypto. With Google (GTS and Chrome), Cloudflare and Let's Encrypt all preferring MTC and legacy CA's like Digicert, Sectigo, Globalsign all heading towards non MTC.
If Cloudflare would not have decied to become a PQ CA for MTC. We would have a duopoly with GTS and Let's Encrypt. This is a worse off situation. Therefore I welcome Cloudflare CA for MTC.
Also, its not like they are going to make any money of the CA business if they are going to issue DV certs for free. It will reduce the pressure on Let's Encrypt from carrying the burden of securing 60% of the world's webistes.
1. sneak · 1790773375 · focus · HN ↗
  > A very welcome move because for years Cloudflare has freeloaded certs from Let's Encrypt without sponsoring Let's Encrypt finacially.
  It's not freeloading to accept a gift freely given. I'm sure the people who do fund LE are happy to see the world's largest TLS terminator using LE certs to secure the web - that is and was the whole point of LE in the first place. It's being used as intended.
2. sekinfo · 1790864302 · focus · HN ↗
  I don't agree that this is a positive development if a resilient worldwide PKI is desired.
  1. We have seen how Cloudflare can "break the Internet" due to their position as a SPoF. Let's Encrypt also became a SPoF as their popularity grew.
  2. Cloudflare's main service depends on breaking the trust model of TLS, which is to say that users must be assured that they can communicate with a server without the possibility that third parties are observing or tampering with the connection. If I direct my user agent to example.com, I expect that my TLS connection is terminated by the operators of example.com, and any contents sent and received are between me and the servers associated with example.com. Cloudflare breaks that assumption by performing TLS interception between my user agent and the server. Yes it is true that other services, such as cloud load balancers, do the same thing, but we should not accept that this creates an important opportunity for interception or tampering due to commercial interest, duress etc.
  3. Furthermore Cloudflare allows operators to present a TLS certificate to clients even when the origin server does not use TLS, leading them to believe that their connection is secure even when the leg between Cloudflare and the server is not encrypted: the so-called TLS façade.
  4. Cloudflare is incorporated in a jurisdiction that has been seen to behave in a hostile, or at a minimum highly arbitrary, fashion, and has been involved in pressuring infrastructure operators to do their geopolitical bidding and personal favors to the executive. Of course Let's Encrypt also has this weakness.
  Are we to believe it is a good thing that a known SPoF becomes an even more critical SPoF? That an actor who subverts TLS becomes a CA? More concentration of infrastructure control in a single jurisdiction that does not respect international norms?
  Cloudflare promoters will say that points 2 and 3 are always the choice of the server operator. However Cloudflare takes advantage of the fact that most server administrators actually understand very little about how TLS, or even the Internet, works. I frequently observe that the operators of critical public services on the Internet fundamentally misunderstand basic technologies such as DNS, IP, TLS and HTTP. For those people, Cloudflare gives them an easy option to "stop the DDoS", without understanding the implications of sending their traffic to a foreign actor who will perform TLS interception. And in many cases, using Cloudflare turns into a ritualistic mimicry that is performed as a preventative rite to placate the DDoS spirits.
  It is also concerning to me the suggestion that CAs which are not GTS, CF and LE are somehow considered "legacy CAs" now. In what sense?
  LE recently updated their policies to say explicitly that they will comply with export restrictions:
  <a href="https://letsencrypt.org/documents/LE-SA-v1.7-June-04-2026-diff.pdf" rel="nofollow">https://letsencrypt.org/documents/LE-SA-v1.7-June-04-2026-di...
  Discussion: <a href="https://news.ycombinator.com/item?id=48453275">https://news.ycombinator.com/item?id=48453275
  Let me remind you that the implied "modern" CAs mentioned must also comply with export restrictions, but furthermore they are subject to non-public pressure dynamics from the executive which may result in arbitrary service terminations at the individual, organization or country levels. This as well as compliance requirements with CLOUD and collection programs.
  I propose that the goal should be to look for a way in which we can have widespread availability of free DV certificates for everyone who needs one, independent of their nationality, from multiple geographically distributed providers in diverse jurisdictions, coupled with a sustainable economic model for CAs which are not operated by the tech giants.
  There are actually non-giant CAs, besides LE, which already provide free DV certs, ACME compatible, for example:
  <a href="https://www.ssl.com/products/website-security/tls-ssl/single-domain/free-dv/" rel="nofollow">https://www.ssl.com/products/website-security/tls-ssl/single...
chaz6 · 1790756951 · focus · HN ↗
The article contains conflicting statements:
> anyone already pointed at any existing free CA can move to us by changing a directory URL, with no new tooling and nothing to re-architect.
> We will only issue to clients that support ACME Renewal Information (ARI), standardized in RFC 9773.
I do not think both can be true.
1. mjmas · 1790758680 · focus · HN ↗
  That only relies on the (mostly reasonable) assumption that all CAs that don't use ACME charge for the service.
2. crote · 1790762390 · focus · HN ↗
  That doesn't sound like much of a contradiction to me: anyone already using standard ACME tooling can change to their new CA with a trivial configuration change - provided their standard ACME tooling is well-maintained enough to include a 5-year-old protocol extension.
edelbitter · 1790764221 · focus · HN ↗
[delayed]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.