Hacker News Reader

Comment by rocqua | Hacker News Reader

That ship has sailed. DNSsec is not liked even a little bit. Given that control over DNS is how domain validated certs are handed out, it would make a lot of sense to cut out the middle man.

But DNS does not have a good reliable authenticated transport mechanism. I wonder if there was a way to build this that would have worked.

View on HN

My biggest problem is how centralized issuance is.

Half the year I live on an island that is reliant on submarine cables and has historically had weeks and months long outages and with a changing world I suspect that might become reality once again. Locally this wasn't much of an issue, the ccTLD continues to function, most services (but now about 35%) are locally hosted. Then HTTPS comes along. Zero certificates could be (re-)issued during an outage. A locally run CA isn't really an option (standalone simply isn't feasible and getting into root stores takes time and money), so you are left with teaching users to ignore certificate errors a few weeks into an extended outage.

I could see someone like LE working with TLD registrars to enable local issuance (with delegated/sub-CA certificates restricted to the TLD), that could also mitigate problems like today (decentralize issuance) and the registrars are already the primary source of truth for DV validation.

Realistically there's no reason except Google retaining centralized control of the Internet for there to be a specific group of trusted CAs that meet Google's arcane specifications which can issue certificates the entire world trusts.

Your registrar should be able to validate your ownership of the domain, ergo your registrar should be your CA. Instead of a bunch of arbitrary and capricious rules to be trusted, a CA should not be "trusted" by the browser, but only able to sign certificates for domains registered to it.

s/Google/Apple, Google, Microsoft, and Mozilla/

Not in any realistic way, no. Because Chrome is by far the majority of the market, so what Google ships is what is available on the web. If Google unilaterally decides it is going to distrust a CA, it doesn't really matter who else does or not, the CA is dead.

Not that the other parties are that independent anyways: Microsoft's browser is a Google fork, and is wholly dependent on it. Mozilla's entire funding is Google. Apple is arguably the only somewhat independent party here, but that multibillion dollar annual search deal... let's say it incentivizes collaboration.

Edge may be a fork of Chromium but they have the capability of shipping whatever roots they want or setting whatever trust policies they want

And the push-down in certificate age is, or at least was at the beginning, a push from Apple. The others have come around/along for the ride

If your concern is breaking Google's stranglehold on the web, why would Google ever implement DANE? (They probably won't, for other reasons they've already stated, but I'm trying to understand your logic).

They wouldn't and that is part of the problem. We are stuck with a fragile and insecure certificate strategy because the existing strategy allows Google significant control of the ecosystem.

The "I support shorter lifetimes so this all comes crashing down" comment I made earlier is arguably a bit facetious, but I do think the PKI wonks in the CAB are pretty much accountable to noone until they break things badly enough that their bosses have to pay attention to the problem.

Antitrust enforcement remains the fix here.

What other mainstream browser are you counting on to ever support DANE?

I feel like this comment ignores the fact that right now all of them are effectively tied to Google, and that supporting DANE if Google doesn't is currently pointless, so obviously no one would until the status quo changes.

Ultimately the problem is that currently "security best practice" as it's commonly discussed, says what we're doing now is a good idea. It's not, and until we change the understanding on that, nobody's going to feel motivated to do better.

Password rotation used to be considered a gold standard strategy for security, until people realized not only did it make everything harder, it also encouraged people to choose less secure passwords and was largely self-defeating.

If I told you we could improve a 90-day password rotation policy by making it change every week, you'd rightly call me crazy, but for some inconceivable reason (monopoly, perverse incentives, appeal to an authority run by idiots, name your choice), people act like decreasing certificate lifetime is somehow going to make the web safer.

Decreasing certificate lifetime addresses a totally different problem than password rotation.

Why do you think so? A certificate is essentially a password that proves your identity and rotating it faster is to ensure it stops doing that if someone steals your password.

Short certificate lifetimes address the fact that TLS certificate revocation doesn't work. Password rotation --- which is no longer a NIST recommendation! --- addresses the concern that long-term secrets eventually leak. You can intuitively see how different the problem domains are from the fact that certificate lifetimes are far shorter than even the old NIST password rotation rules were, despite the fact that certificates are all stored securely relative to passwords.

But whether that's intuitive for you or not, the fact remains: short-lifetime automated certificate provisioning is a response to revocation.

I do see your position re: passwords tend to successfully be canceled and certificates tend to not. But I would certainly argue that the downsides of rotation on user behavior and technical security design are quite costly. They remove a lot of the opportunity for risk-based authentication (like TOFU) and require people set up fragile automations capable of generating keys that claim to be them. And every certificate warning that isn't due to a real security problem creates alert fatigue that makes certificate errors seen as spurious.

I think short certificate lifetimes will be viewed in the relatively short future as misguided as the old NIST recommendation on passwords.

We have short lifetimes because TLS revocation doesn't work. It's that simple.

To understand the distinction, imagine a password system where you can't change your password. You can make new ones, but the old ones still work. That's the problem TLS was facing.

Even granting that, it's still both an ineffective fix and it introduces significantly worse security risks than it tries to mitigate, on a system that at its core is fundamentally bad.

PKI is structurally broken at every level. The reason there are so many changes and additions and new features being slapped on it, is because it's a really dumb system and the people who control it are very motivated to keep it in place at the expense of everything else.

No, it doesn't.

Not quite that simple, no. It's a good reason, and while CRL and OCSP don't really work well - CRLite/OneCRL, CRLsets and valid all go some way to making revocation reasonably effective. Having an effective way to rotate all certificates, quickly, is a bigger reason. 1k -> 2k RSA took too long. SHA1 -> SHA2 took waaaaay too long. Changing anything about the webPKI takes too long unless everyone is on short lifetimes. The post-quantum bogeyman looms, too. Heartbleed and unforced CA errors become way less of a problem is everyone is forced to rotate monthly.

Fair enough (I knew someone was going to come in here and whack me on this). I'd only say that this makes the overall argument for short-lifetime certs even stronger. :)

…and I didn’t even have to play the SC-081 sponsor card either ;)

> Password rotation used to be considered a gold standard strategy for security, until people realized not only did it make everything harder, it also encouraged people to choose less secure passwords and was largely self-defeating.

Even if we ignore the fact that certificates are not a secret, and that expiry applies to certificates, not private keys, a major difference is that humans don’t mentally generate or manually type TLS keys or certificates. So the negative impact of rotation on user experience and behavior is entirely absent.

I was drastically oversimplifying by calling certificates a password. But the point actually does definitely stand: In the long-lived certificate days, you'd keep your CAs and such offline, and generally speaking, highly secured. Now you have to give your automations everywhere everything they need to constantly generate keys that claim to be your site. People are pushed to make drastically less secure choices about how they generate certificates because it needs to happen so often. A lot like adding a 1 on your last password. ;)

Also, short lifetime certificates help deprogram concern about certificate warnings (most nontechnical users know to ignore them, as a network admin, I've never seen a certificate warning that was actually due to a compromise... so I also ignore them all), which leads to hypothetically much less safe behavior than if certificate warnings only happened when rational.

Which is to say, if you believe a certificate that expired yesterday should result in a scare screen to users or worse with HSTS, interfering with the ability to access it all, you failed security 101.

Reply on news.ycombinator.com