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

Chromium and Mozilla to enforce 1 year validity for TLS certificates

chromium.googlesource.com

Post reply on HN
Print view View original

141–150 of 375 posts

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#141

Post by tonetheman »

wolf550e wrote: post #10
markstos wrote: post #5

This may be good for security, but it is extra burden for small web developers and individuals. Big players will have cert renewals automated. It's possible and free for small players to use letsencrypt, that still takes some time to set up, manage and maintain over time. Without automation, you've got an annual chore to do or your site goes offline. I think some hosts are already starting to offer free and easy SSL…

Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?

Lots of people. Such arrogance from those who post on hackernews.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#142

Post by wolrah »

znpy wrote: post #71
SquareWheel wrote: post #12

To clarify, this is the limit for how long they can be to be considered valid. Certificates are encouraged to be of shorter lengths as it reduces their potential for abuse. If compromised, a certificate with a long lifespan could be used for years without anyone noticing. A system which doesn't check for revocation is especially vulnerable (though of course, browsers do). Let's Encrypt certificates are only valid thr…

> To clarify, this is the limit for how long they can be to be considered valid. to be fair, there's already a the concept of certificate revocation list and OCSP (on-line certificate status protocol) that helps in order to check the validity of a certificate (that is, whether it has been revoked or not). While short-lived certificates are fine for letsencrypt, pushing the same for the rest of the world looks a bit l…

The problem with certificate revocation is that a lot of software treats it as a soft-fail if revocation status can't be verified, rather than a hard fail.

That is one of the main reasons for LE's short lifespan. Certificate revocation is not reliable in practice.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#143

Post by AdamJacobMuller »

xg15 wrote: post #103
dharmab wrote: post #65

Earlier quoted context omitted.

Buy a domain, create a subdomain for local use, and issue ACME certs with Let's Encrypt every 60 days. If your vendor device or software doesn't support automated certificate rotation, put nginx/haproxy/envoy in front of it.

This won't work either, btw: You'd have to request from Let's Encrypt a new certificate for each individual device . LE has several rate limits that will prevent that from working for anything more than a trivial number of devices: https://letsencrypt.org/docs/rate-limits/ The only way I see how this would work is if you not just purchase a domain but also an internet-facing server and do the renewal and certificate…

This will work fine. LetsEncrypt will raise ratelimits for you. I've done it for a commercial CDN and they were very accommodating and helpful.

Plex does this, for example, though they use DigiCert's free certificates: https://www.plex.tv/blog/its-not-easy-being-green-secure-com...

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#144

Post by AdamJacobMuller »

MikeHardman wrote: post #115
xg15 wrote: post #103

Earlier quoted context omitted.

This won't work either, btw: You'd have to request from Let's Encrypt a new certificate for each individual device . LE has several rate limits that will prevent that from working for anything more than a trivial number of devices: https://letsencrypt.org/docs/rate-limits/ The only way I see how this would work is if you not just purchase a domain but also an internet-facing server and do the renewal and certificate…

You can do wildcard certs with LE, I run hundreds of k8s services all secured with LE and wildcard certs.

You can, but, you can't (by policy) distribute keys across multiple customers.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#145

Post by cutler »

detaro wrote: post #128
cutler wrote: post #104

Earlier quoted context omitted.

Agreed. Talk about sledgehammer to crack a nut. Typical sysadmin solution to a problem assuming every Joe Blogger is going to setup his own VPS and fsck with certbot.

Joe Blogger is not expected to setup a VPS, Joe Blogger is using shared hosting or a blog-as-a-service, and thus leaves worrying about how to implement HTTPS to someone else.

So the death of self-sufficient, independent Joe Blogger espcially if that "someone else" is his hosting provider who doesn't handle Letsencrypt.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#146

Post by hannob »

greatgib wrote: post #136

Remember the good old time when it was not an almighty cartel of browsers that controlled your internet? This is so an arbitrary decision and so much a pain in the ass. Again, a limited number of people used their corporate interests to decide for the whole world with almost no discussion. The worst is that the "security" argument for this change is quite weak. Yes, we can think that shorter certificates are a little…

Yeah those good old times when Comodo was hacked and issued certificates for gmail.com and nobody really cared. Or when some shady CAs sold intermediate certificates in devices so you could man in the middle all your network connections (and everyone else's, too).

So bad those times are over and we have this browser cartell enforcing some basic security standards for TLS. Screw them!

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#147

Post by elcritch »

paledot wrote: post #57

With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I'm wondering if it's the manufacturer's fault or if that use…

It’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices/services and that the identity isn’t verified by https like most sites.

The issue lies between the browsers and https system. SSH can do encryption without requiring identity verification. It handles it by asking "Do you want to trust this new server?". Then if it changes informs you of that. Browsers could easily implement that for .local with self-signed certs.

Of course browser developers assume everyone has internet all the time and you only access servers with signed domains. I’ve wondered what it’d take to get an ITEF/W3C RFQ published for .local self-signed behavior.

(Edit: RFQ, not my autocomplete’s RTF)

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#148

Post by staticassertion »

lawnchair_larry wrote: post #90
staticassertion wrote: post #31

Earlier quoted context omitted.

Responsibilities have changed a bit. If you're going to host a website you are going to have to put a modicum of effort into ensuring that you are not harming others by doing so.

This is silly to use as a blanket statement. There is nothing harmful about hosting a website. Especially personal sites, internal sites, or small businesses who use it as little more than a brochure that serves static content. My roof repair guy is not harming anyone by posting his information on a basic website.

What if I visit your roof repair guy's site and content is injected, informing me that they now take payments online? Or that I can download their special Roof Repair App to manage my bookings? Or it contains an exploit payload?

It is extremely uncommon for me to actually visit an HTTP website - I even have HTTPSEverywhere block them by default, so I'd know if I were. That means that I am relatively protected to such avenues until I visit your roof repair guy's website.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#149

Post by stefan_ »

PersonalOps wrote: post #140
stefan_ wrote: post #117

Earlier quoted context omitted.

Why as a vendor would you use a self-signed certificate that causes the browser to scream at the customer when you could just not use TLS, plain old HTTP.

Because the alternative is to embed a TLS private key that would allow you to MITM every other one of those devices. Someone extracted it? Looks like you have to either (a) bury your head in the sand or (b) rollout an expensive recall to change certs on those devices. Why use slightly compromised HTTPS versus plaintext HTTP? Same reason they have those super cheap locks on diaries from the 90s: it's a deterrent. Make…

You have already answered why no one in their right mind would embed a shared certificate across all devices. I don't think you are being realistic with yourself when you believe people use self-signed certificates; they don't.

You are missing what happens instead. There is just simply no web management interface on the device anymore. You need to download the vendors app to configure and use the device. Maybe, if the vendor cares, they use their own CA to secure a local connection to the device. Much more likely, the app and device exclusively talk to their cloud and use that as a middleman to exchange information.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#150

Post by paledot »

AdamJacobMuller wrote: post #139
paledot wrote: post #57

With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I'm wondering if it's the manufacturer's fault or if that use…

I'm not a huge fan of it, but, it seems like the way things are going is to simply run a service which is basically a large proxy. Your device connects out with some kind of persistent connection to their central service then requests to your device go to their server, which does AAA and routes to your local device. Fixes the SSL issue, avoids any NAT headaches, enables fully remote access and most importantly for PM…

I think this is the only practical answer, unfortunately. Everything else might possibly be made to work for a personal project, but definitely isn't an option at scale.
Post reply on HN