Live data from Hacker News

Chromium and Mozilla to enforce 1 year validity for TLS certificates

chromium.googlesource.com

281–290 of 375 posts

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

#281
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?".

The problem is to figure out whether to trust the server you need to get its fingerprint through another channel. Is there an HTTPS equivalent of that?

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

#282

Earlier quoted context omitted.

>are not harming others How is HTTP harmful when you visit my website about amateur radio? An expired cert is no more harmful than bare http in this non-commercial non-institional personal context. It's the one being discussed in this sub-thread in case you missed it and assumed the normal HN business context. The burden is real and completely unecessary for personal websites. This makes the web more commercial by im…

We have had this conversation to death: https://doesmysiteneedhttps.com/

I find some of the arguments on that page, uh ... unhelpful at best. Circular, even.

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

#283

Earlier quoted context omitted.

CAs are resting all and every changes because it's easier, it makes sense.

CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.

> the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt

Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)

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

#284
post #267

Earlier quoted context omitted.

What are some valid reasons not to use LetsEncrypt?

It’s extremely insecure if you’re worried about things beyond passive mass surveillance. If someone can intercept traffic to your server IP, they can get a Let’s Encrypt certificate. If they can’t reliably man in the middle that IP, then HTTP is reasonably secure already. Such “certificates without certification” This is one reason browsers have added new UI elements for certified domains.

> This is one reason browsers have added new UI elements for certified domains.

Can you elaborate?

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

#285
post #124
post #89

Earlier quoted context omitted.

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.

Better not do business with shady companies then.

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

#286
post #281

Earlier quoted context omitted.

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?". The problem is to figure out whether to trust the server you need to get its fingerprint through another channel. Is there an HTTPS equivalent of that?

You don't need to get the fingerprint through another channel. Getting the fingerprint through another channel prevents some classes of attacks. Blindly storing the first fingerprint offered also prevents a variety of attacks.

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

#287
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 would be nice if there were a way to be a CA for a subdomain. Then each manufacturer could sign *.mydevice.com.

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

#288
post #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.

Installed? Everyone?

It would be enough to send it as an intermediate CA cert, no need to install.

Going the self-signed DNS name restricted CA way would likely still not fly with browsers, because there's no way to securely deploy the trust root. (Because if it requires user interaction to install that can be exploited by malicious actors.)

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

#289

Earlier quoted context omitted.

Really. This: https://jamielinux.com/docs/openssl-certificate-authority/ gives you a CA in about an hour. HashiCorp Vault will give you a CA in 5 minutes. certstrap will give you a CA in 15 seconds. It’s 2020, it ain’t voodoo anymore.

Just spinning up a CA is a couple of commands. Running one sanely (to include security of the private keys, availability and auditability of the signing machine, keeping backups, publishing a CRL, setting up ACME if you want any kind of automation) is significantly more involved.

Nothing different than any long lived component in any infrastructure. There is no reason to look for reasons not to use a CA.

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

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

You've got it backward. It is a boon for small players and troubles for large companies.

Small players can easily get certificates manually or automate. The platforms/tools they use often give certificates out of the box (cloudflare, heroku, wordpress, etc...).

Large players can't manage certificates. Developers/sysadmins can't use let's encrypt because it's prohibited by higher up and blocked. Even if they could use it, it's not supported by their older tools and devices. The last large company I worked for had no automation around certificates and the department that handled certificate requests was sabotaging attempts to automate, possibly out of fear of losing their jobs.

Post reply on HN