Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

Post reply on HN
Print view View original

281–290 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#281

Post by ameliaquining »

xnorswap wrote: post #126
ameliaquining wrote: post #108

Earlier quoted context omitted.

Is there a different implementation timeline that you think would adequately address the legitimate concerns of orgs relying on legacy and manual processes? My model is that beyond a baseline of a couple years (which were already granted), adding more time doesn't help, because these orgs will always procrastinate until the last minute on anything that doesn't seem to management like an obvious immediate priority. I…

Just extending the timeline won't help, as you suggest, if anything it'll make the problem even worse, by further bedding in the helpless. What typically does work for this kind of thing, is finding a hook to artificially rather than technically necessitate it, while not breaking legacy. For example, while I hate the monopoly that Google has on search, it was incredibly effective when they down-ranked HTTP sites in f…

I can't see them doing that, because whether a site is using HTTPS is visible to end users, and Google and many others had already spent a lot of time and effort getting them to notice and care. By contrast, end users know nothing about certificate lifetimes, so it would be hard to explain this change to them.

Re: SSL certificate requirements are becoming obnoxious

#282

Post by tzs »

tptacek wrote: post #220
tzs wrote: post #200

I've only put maybe 2 seconds of thought into this so it is probably stupid, but why don't we have an alternative that does not require third party certificate authorities? For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain? I see two objections of…

Downgrade protection. It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509. If you have to have an X.509 WebPKI certificate no matter what, then the alternative root of trust just adds attack surface…

> It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509.

Is this because DNS traffic often is not encrypted, so middleboxes can see and meddle with DNS traffic?

Re: SSL certificate requirements are becoming obnoxious

#283

Post by Intermernet »

LeifCarrotson wrote: post #151
znpy wrote: post #112

Earlier quoted context omitted.

Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. > PKI isn’t a solved problem. PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips ) let you create a cryptographically-strong CA and build the automation you need. I…

> It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? The updated (full color!) Panelview HMI is running Windows CE 6.0, so it's perhaps more likely to be compatible, but I don't think…

I had to automate a Fiery controller on a Konica Minolta network printer about 20 years ago. It was running vxworks. I used expect.

I've automated certificate upgrades on everything from dodgy network appliances to IBM System i servers.

I've used everything from headless browsers to scripted 5250 terminal emulators. Generally, if you have the will, you can automate anything that you do manually. The solutions are often janky, but they can usually be verified easily by other tools (curl output can be parsed to verify cert details).

Re: SSL certificate requirements are becoming obnoxious

#284

Post by tptacek »

tzs wrote: post #282
tptacek wrote: post #220

Earlier quoted context omitted.

Downgrade protection. It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509. If you have to have an X.509 WebPKI certificate no matter what, then the alternative root of trust just adds attack surface…

> It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509. Is this because DNS traffic often is not encrypted, so middleboxes can see and meddle with DNS traffic?

It's because DNSSEC records look nothing like typical DNS records --- they're very large --- the same middleboxes can drop things like TXT records too, but those are less crucial for ordinary browser users.

Re: SSL certificate requirements are becoming obnoxious

#285

Post by Shank »

plorkyeran wrote: post #228
TurboSkyline wrote: post #219

Earlier quoted context omitted.

> But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. EV certificates are no longer in use? Do you know why?

They turned out to be expensive theater. One major problem is that company names aren't actually unique. An EV cert for "Stripe, Inc" still doesn't tell you that you're talking to the correct "Stripe, Inc". The other big problem was that users had no clue they were a thing, and when browsers tried to emphasize them in the UI it just confused users and made phishing easier . You can still buy EV certs if you want to d…

> You can still buy EV certs if you want to donate money to a CA, but that's about all they accomplish.

To be more precise, the browsers de-emphasized them and removed any distinguishing marks or indicators that made them valuable. EV certs used to display the company name in the URL bar, but they were stripped back.

Re: SSL certificate requirements are becoming obnoxious

#286

Post by allan_s »

Muromec wrote: post #168
allan_s wrote: post #157

Earlier quoted context omitted.

For regulatory requirements: yes ! I currently for EIDAS certificates, I can only choose a vouched certificate provider, and it's mostly somes that requires me to in person with my ID card with someone verifying the guy who made the CSR is actually me. The certificate is used for double SSL to authentify the server doing the request , i.e that the server doing an API call to the bank server is one I own. (I find it a…

Well, its eidas, ofc you need to show the id

I know, it was to give example of why not every certificate can be "let's encrypt" and why some people still pay for certificate in 2025.

Re: SSL certificate requirements are becoming obnoxious

#287

Post by nickf »

ocdtrekkie wrote: post #277
nickf wrote: post #273

Earlier quoted context omitted.

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.

Re: SSL certificate requirements are becoming obnoxious

#288

Post by nickf »

luma wrote: post #81
pelagicAustral wrote: post #47

Earlier quoted context omitted.

I work for government and I can tell you the guys working infrastructure are still paying for shitty SSL certificates every year, in most cases for infrastructure that doesn't even see the light of day (internal), and the reason for that is none other that not knowing any better, and being unable to get their head out of their asses for enough time to learn something novel and implement it in their workflow. So yeah,…

Alternatively, those people are dealing with legacy systems that are pathologically resistant to cert automation (looking SQUARELY AT YOU vmware) and elect for the longest lasting certs they can get their hands on to minimize the disruption. It’s generally best to assume experts in other fields are doing things for good reasons, and if you don’t understand the reason it might be something other than them being dumb.

If there are systems that are that resistant to automation, the question should be 'does this system need a publicly-trusted server certificate, the same as a blog about cats or a Shopify shop?'. The answer is no. If it can't practically be automated, it near-certainly doesn't need to have a public cert on it.

Re: SSL certificate requirements are becoming obnoxious

#289

Post by nickf »

holoduke wrote: post #113
Intermernet wrote: post #38

Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly. I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a w…

Older Android 7 devices are not supported with letsencrypt. For us still 20% of our userbase. We went for a paid subscription with zerossl.

It's likely to get worse as CAs rotate roots more frequently. Cross-signing will work for a time (provided you correctly install) but at some point, older devices will drop out of support and that'll be it.

Re: SSL certificate requirements are becoming obnoxious

#290

Post by ocdtrekkie »

nickf wrote: post #287
ocdtrekkie wrote: post #277

Earlier quoted context omitted.

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.

Post reply on HN