Live data from Hacker News

Chromium and Mozilla to enforce 1 year validity for TLS certificates

chromium.googlesource.com

121–130 of 375 posts

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

#121
post #54

Earlier quoted context omitted.

No... web of trust is an important aspect to https.

s/web of trust/centralization/

s/centralization/validating ownership

Without centralization I can MITM at the coffee shop and steal passwords.

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

#122
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…

[deleted]

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

#123
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.

We're talking about customer hardware. If someone looks at the insides of the device and finds, of course, the private key for your one shared wildcard certificate, the issuer is required to invalidate it immediately.

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

#124
post #89

Earlier quoted context omitted.

One reason for these proposals was to put pressure on the SSL certificate ecosystem to provide (CAs) and adopt (hosting) automated SSL renewal practices. Businesses have had three years since Let's Encrypt first went live to adopt such practices, but many chose not to — not just hosting providers, but e.g. bigcorp load balancers too.

Guess what - not all websites are businesses. In fact not all websites are dynamically-generated so why the fsck do we all have to put up with this madness? Make HTTPS/SSL necessary for transactional sites but for simple static sites give me a break.

did you know there are ISPs out there that inject garbage code into the html of unprotected sites?

get out of here with this HTTPS is unnecessary tedium.

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

#125

Earlier quoted context omitted.

TOFU is a viable alternative for "long-living" certs, too. The very fact that the cert has longer validity makes it somewhat easier to trust it directly in the client.

TOFU doesn’t actually work. If you set up a TOFU cert environment, 100% of non-security people will click right through it, and 95% of security people will also click right through it. They’ll just assume that because it was untrusted the first time, that cert errors are normal and ignore it. Especially since they will have a “first use” for every new device and every new browser they visit with.

Funny how some people claim no one will ever click thru the TOFU warning screen because it's too scary and unfamiliar, whilst others say users will just click thru everything.

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

#126
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 that wouldn't quite work for the prosumer router manufacturer case the OP mentioned: LE would revoke the cert once you distributed it.

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

#127
post #102
post #66

Earlier quoted context omitted.

Without buying a domain. (and continously spending money to keep it owned)

There’s always the .local TLD, which is reserved for this use case: https://en.m.wikipedia.org/wiki/.local

That works, but you can't get public certs for it, because you can't prove you own that domain (indeed, you don't :))

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

#128
post #104

I don't like seeing how the SSL hurdle affects small read-only websites.

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.

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

#129
post #94

Earlier quoted context omitted.

Websites marked "insecure" are still fully accessible.

Not always. Sometimes the browser presents a full-page response to the effect that the site is dangerous at which point, even if it's a harmless site, the non-savvy user will leave. Blanket HTTPS/SSL + Letsencrypt is a disaster.

This only happens if the site used to be HTTPS and no longer has a certificate or the site has long-lasting HSTS.

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

#130
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…

If only we had NameConstraints: we could have a CA limited to *.clientdevices.manufacturer.com, installed in everyone's trust root.
Post reply on HN