Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's not how this would work.

Based on previous history where people actually did call google's bluff to their regret, what happens is that google trusts all current certificates and just stops trusting new certs as they are issued.

Google has dragged PKI security into the 21st century kicking and screaming. Their reforms are the reason why PKI security is not a joke anymore. They are definitely not afraid to call CA companies bluff. They will win.



How is "client certificates forbidden" in any way an improvement?


As a general rule in cryptography, a lot of vulnerabilities relate confusing the system by using a correct thing in the wrong context. Making it a rule that you have to use separate chains for separate purposes is a good rule from a general design standpoint.


> Making it a rule that you have to use separate chains for separate purposes is a good rule from a general design standpoint.

No it's not. It's a specific argument, that's true only in specific cases. You shouldn't handle knives, is equally a good rule from a general design standpoint. But nonsensical when you're a chef.

You should have separate chains is a reasonable decision when the ability to rotate out a compromised chain, and insulate some downtime, from other chains/usages is desirable. Needing to manage multiple cert chains is more overhead. Making use or maintenance harder. It increases complexity.

Large companies have never been afraid of more overhead. It's their singular advantage.

Removing features someone is using, and calling it better security, when it doesn't actually meaningfully reduce or remove some risk is weaponized incompetence. And sufficiently advanced incompetence, is....

There's no world where anyone gains additional protection, from a 3rd party compromise. Or one where LE has one of chains compromised, but doesn't rotate all of them.


Except we didn't get a separate chain - all we got is that from now on software will just ignore the "client" flag and accept the "server" flag for client purposes, adding one more hack onto the pile of hacks that is the Internet.


That's far from clear. XMPP is still probably a minor use caee of client certificates.


Yeah buy why would anyone go through the trouble of bootstrapping a whole new PKI instead of just flipping an if statement?

I'm curious what other use cases there have been for domain-validated client certs aside from XMPP.


So, FUD.


Not forbidden, just not going to be a part of WebPKI.

It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).


What exactly do you mean with "WebPKI"?

The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.


The current PKI system was designed by Netscape as part of SSL to enable secure connections to websites. It was never independent of the web. Of course PKIs and TLS have expanded beyond that.

"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.


The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules.

You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.


> What exactly do you mean with "WebPKI"?

WebPKI is the name of a specific PKI system, where PKI us a generic term for any PKI.


Google didn't drag anyone anywhere without LE though.

Sure, they supported the nascent HTTPS very early on, but most of the web thought that certificates were "too expensive for the likes of us", and so only really banks and the like actually adopted HTTPS. Most of the internet was still HTTP only for years after HTTPS was available.

Only when LE came along and started offering free certificates and facilitated a massive uptake in HTTPS websites were Google ever in a position to default to marking HTTP as "insecure and dangerous".

I've got no figures, but I suspect that if LE were to kick their heels in, that Google wouldn't dare risk half the internet not working using their browser. I'm sure that would be some people who didn't want to be collateral damage if there was a standoff and would switch to a CA that complied with Google's will, but I suspect most people would be happy to see Google challenged on this. And end users would hopefully discover that every other browser still worked, just Chrome had broken, and Chrome would quite rapidly fall out of favour.


While google did do a lot of work on making https by default be a thing, that is only a small part of what im refering to. Google did huge amount of work to make https high quality, so that sites using it were actually secure. They increased standards for CAs significantly, took a much tougher line on CAs who violated the rules, pushed certificate transparency hard (which is probably one of the most important developments for security of TLS ecosystem). Chrome was the first browser to support HSTS which is very important for https to work in practise. Google maintains the hsts preload list.

Google didn't just make TLS popular, they made it secure.


Dragging PKI into the 21st Century! Just like they dragged manifest v3 into the 21st century!

It's for your own good dontchaknow!


It's how it should work but the supposed CA browser "forum" has become a browser dictatorship. While there have been issues where CAs were dragging their feet, just letting Google dictate whatever they want is not the solution.


>what happens is that google trusts all current certificates and just stops trusting new certs as they are issued.

Given that LE renews certs every few weeks that wouldn't take long




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: