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

311–320 of 375 posts

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

#311

Post by CountSessine »

Spivak wrote: post #269
CountSessine wrote: post #243

Earlier quoted context omitted.

So the answer is to subvert the global certificate infrastructure that protects web traffic? No, it isn’t. Your IoT device has no security at all if a non-technical user is setting it up or if it doesn’t have a way of accepting a user configured certificate, and you shouldn’t pretend otherwise by dressing it up in bad certificates and worthless encrypted tunnels. Just use HTTP.

I mean if they’re worthless tunnels then so is every SSH tunnel. Should we just go back to telnet?

On your own network? Does it really matter whether you use telnet or ssh? And if it’s on a shared network, don’t you have an IT department that can set up the local key infrastructure and push out certificates?

The argument here is that we should enable lots of shitty IoT devices to masquerade as being secure, and inure browser users to click ‘yes’ to accepting a broken certificate.

If it’s on a managed network, IT can set up a certificate and push that out to client machines. If it’s on your home network you can do that (unless your IoT device can’t take a user configured client cert, in which case it’s rubbish anyways), and if you can’t then you might as well use HTTP.

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

#312

Post by Avamander »

majewsky wrote: post #283
londons_explore wrote: post #62

Earlier quoted context omitted.

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? :)

And that's two out of how many?

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

#313

Post by elcritch »

p2t2p wrote: post #101
xg15 wrote: post #87

Earlier quoted context omitted.

I admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server. There remains the question how I would get the CA certificate onto client devices in the first place. Lastly, with asking consumers to install a CA certificate…

It is no more complicated than a self signed certificate. Two clicks in Firefox, 4 taps in iOS

Every time and no tracking if device indentity changes.

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

#314

Post by [deleted] »

Karunamon wrote: post #237
jt2190 wrote: post #102

Earlier quoted context omitted.

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

That article goes on to state that .local is reserved by RFC6762 (multicast DNS), which if you use that domain on your network, will cause problems with any services using it, usually Macs or iPhones. This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meanin…

[deleted]

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

#315

Post by [deleted] »

Karunamon wrote: post #237
jt2190 wrote: post #102

Earlier quoted context omitted.

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

That article goes on to state that .local is reserved by RFC6762 (multicast DNS), which if you use that domain on your network, will cause problems with any services using it, usually Macs or iPhones. This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meanin…

[deleted]

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

#316

Post by CountSessine »

riskable wrote: post #275
filmor wrote: post #258

Earlier quoted context omitted.

HTTP traffic would be unencrypted, so everyone (esp. on Wifi) could record passwords etc. flying around. With HTTPS, you at least need to MITM the connection to do that. If you establish trust in some other way (cert ID printed on the device?), the connection is secure.

Not just intercept: Using HTTPS prevents messing with the connection in-flight. So an attacker won't be able to inject their own payload into that web page you just requested.

Except you’re using garbage certificates so anyone could MITM you and inject whatever they like.

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

#317

Post by tialaramex »

gpm wrote: post #79
waheoo wrote: post #53

Earlier quoted context omitted.

Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.

It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/

However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange.

That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...

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

#318

Post by xtracto »

jjcon wrote: post #183
brian-bk wrote: post #178

Earlier quoted context omitted.

> It's possible and free for small players to use letsencrypt, that still takes some time to set up, manage and maintain over time. If you want to run a webserver but are unable to set up a cronjob that does certbot renew you don't deserve external users. Full stop. If it's just you and you don't care about your own security, then do whatever you want in your own browser.

> you don't deserve external users. Full stop. It’s shit attitudes like this that killed the old internet we all loved

Don't feed the 5 hour old troll account.

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

#319

Post by CountSessine »

drdaeman wrote: post #274
CountSessine wrote: post #250

Earlier quoted context omitted.

What would it say? “You’re connecting to an IoT device that has a worthless certificate. Would you like me to open up a completely pointless AES256 session with it and pretend that you have a secure connection?” Just use HTTP.

(Disclaimer: I'm not a security expert). Ideally, I think, something like this: "You're trying to connect to a new device on your local network. To ensure the security please check that the device has a display or a printed label that says 'HTTPS certificate ID: correct horse battery staple couple more random words'?" (mobile devices may suggest to scan a QR code instead). I'm pretty sure if at least one major browse…

It certainly sounds a lot better than simply asking browser vendors to give .local a pass on cert validity.

I’m still wary of any flow that would have browser users “accepting” a device as secure - could I impersonate that device on the local network? Could I convince someone to accept a site on the wider internet as their IoT device? Someone smarter than me needs to think hard about these questions.

Maybe another approach would be to build infrastructure (like protocols and client software) to make building a home cert chain easy? A windows client that would let you create a root cert, install it in your cert store, and then give you server certs to hand out to devices? Give it a consumer friendly brand name or something and get IoT vendors to add a front-and-centre option to adopt a new server cert.

Authentication isn’t a tricky problem; it’s the trickiest.

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

#320

Post by gsich »

riffic wrote: post #291
gsich wrote: post #285

Earlier quoted context omitted.

Better not do business with shady companies then.

or you could follow established best practices and secure your site with TLS.

Both. I am not responsible if you chose a shitty ISP.
Post reply on HN