Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

I do not think PKI will survive the 47 day change. I am not sure the CAB will survive that change. It seems extremely apparent the people who made the decision have neither any relevant experience in IT nor any practical understanding of security, and I think they've finally flown too close to the sun.

Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer.

In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.

View on HN

>Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer.

???

All my servers use certbot and it works fine. There's also no shortage of SaaS/PaaS that offer free ssl with their service, and presumably they've got that automated as well.

Out of about three dozen places I need a certificate, I believe one recently added support for ACME. Tell me you aren't in enterprise IT without telling me you aren't in enterprise IT. ;)

It may help you to understand that it is not an assumption any given product even supports HTTPS well in the first place, and a lot of vendors look at you weird when you express that you intend to enable it. One piece of software requires rerunning the installer to change the certificate.

Yeah, there are also some very expensive vendors out there to manage this for big companies with big dollars.

Your perspective may be just as narrow, albeit from the other end of the spectrum. Huge heaps of things do work just fine with ACME now, or support being fronted by a reverse proxy which does.

Plus, how would you ever get enterprise tool vendors to add support if not for customers pestering them with support requests because manual certificate renewal has gotten too painful?

> I do not think PKI will survive the 47 day change. […] In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.

Maybe PKI will die… or you will. Progress doesn't treat dinosaurs too well usually.

Put a reverse proxy in front of it. Write a script. Use RPA for the really obnoxious ones. There are lots of workarounds.

What would it look like for the Web PKI to "not survive that change"? Is the idea that companies stop having websites and tell all their users to switch to Gopher or something, because the burden of certificate management is too much?

> In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.

Good. A certificate being publicly trusted is a liability, which is why there are all these stringent requirements around it. If your certificates do not in fact need to be trusted by random internet users, then the CA/B wants you to stop relying on the Web PKI, because that reduces the extent to which your maintenance costs have to be balanced against everybody else's security.

As I said in another comment, private CAs aren't that popular right now in the kinds of organizations that have a hard time keeping up with these changes, because configuring clients is too painful. But if you can do it, then by all means, do!

> What would it look like for the CA/B to "not survive that change"?

I suspect when companies who are members actually realize what happened, CA/B members will be told to reverse the 47 day lifetime or be fired and replaced by people who will. This is a group of people incredibly detached from reality, but that reality is going to come crashing through to their employers as 2029 approaches.

> Good.

You may assume that most organizations will implement private CAs in these scenarios. I suspect the use of encryption internally will just fall. And it will be far easier for attackers to move around inside a network, and take over the handful of fancy auto-renewing public-facing servers with PKI anyways.

Who exactly in the CA/B member companies is going to demand that the 47-day lifetime be reversed, and why are they going to do that?

If an org is tech-forward enough to have bothered setting up HTTPS for internal use cases on their own initiative, just because it was good for security, then they're not going to have major problems adapting to the 47-day lifetime. The orgs that will struggle to deal with this are the ones that did the bare minimum HTTPS setup because some external factor forced them to (with the most obvious candidate being browsers gradually restricting what can be done over unencrypted HTTP). Those external factors presumably haven't gone anywhere, so the orgs will have to set up private CAs even if they'd rather not bother.

I think when Sundar and Satya start hearing about how their customers are losing billions of dollars because of some random people at their company called "certificate trust program leads" or whatever, there is going to be a lot of questions how those decisions got made and how to get them un-made.

Most of the other forum members either won't oppose longer lifetimes (every cert vendor would be happy) or will bow to the only two companies that matter.

Nothing even remotely similar to that happened on previous tightenings. Going from not a peep to enough outrage to overturn a decision this thoroughly debated all at once seems really unlikely. Also, what are the aggrieved enterprises going to do, threaten to move from GCP to AWS if Chrome doesn't do what they want? That's an empty threat and everyone knows it.

None of this will happen. Saying this as the named endorser for SC-081.

I really would like to share with you that what you endorsed will cause deaths. Deaths never attributed directly, sure. But the damage to the stability of the Internet of this is immense, and the impact that will have on individual lives virtually unpredictable in millions of complicated ways.

And I really hope you are wrong that it will not get reversed. (I hope I am wrong about the above, but I doubt it.)

It will not be reversed, of that I'm certain. Attributing deaths, even indirectly, to the change in duration of TLS server certificates for the webPKI is incredibly extreme. If you have any real evidence or data to share, I have resources and my own time to investigate.

Like, you do understand the Internet is the world's largest life-critical system, right? For dozens of reasons (including the CA/B), it really shouldn't be, but it is. When a medical device breaks due to a certificate error, that's going to be on you. Heck, when a doctor can't find the right information at the right time because of a certificate error, that is on you. Should SCADA systems controlling critical infrastructure use PKI? No. Does it? Yep, everywhere. There are virtually endless things where the Internet working is in the critical path of life-saving and life-changing processes, not because they should be, but because the stack of technology is deep and confused and people make bad decisions. And the cool thing about automation is nobody looks at it until it unpredictably breaks.

When the Internet breaks, people die. It's all fun and games to talk about hypothetical security problems that you aren't actually solving as an excuse to make the Internet incredibly transient and fragile, but it has a real human cost.

Right now, over 80% of organizations have outages do to a certificate issue every year. That's really bad, and already due to the CA/B's poor decisionmaking. But at the existing certificate lifetimes, at least it's predictable. Now the CA/B wants to multiply the possible problem occurrences by a factor of ten. And an organization can't even just be concerned with their own certificates, because any layer of their stack's software or infrastructure having a certificate error can have downstream effects.

The reason I believe this change will be undone, is because ultimately it will have to. It will be so obviously wrong if it goes into effect that people opposed to undoing it will get removed from the decisionmaking until it is undone.

Do you have an order-of-magnitude estimate of how many deaths?

Reply on news.ycombinator.com