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

361–370 of 375 posts

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

#361

Post by heavenlyblue »

robocat wrote: post #342
heavenlyblue wrote: post #163

Earlier quoted context omitted.

I would be happy if my router supported letsencrypt. Why would I even bother copying and distributing self-signed certificates if I can just properly get a certificate for my own personal router? It’s idiotic that people still trust pure HTTP and have no option of switching.

If your router needs configuring before it can access the Internet, then it can’t use certificates that require the internet to generate or validate. Or if you change ISP and need to change your router internet connection configuration, your router cannot be accessed.

When was the last time you needed to configure your router to access the internet?

I understand if that router is something industrial, but then you can probably figure out how to do that over SSH anyway (which is secure).

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

#362

Post by jt2190 »

Karunamon wrote: post #358
jt2190 wrote: post #355

Earlier quoted context omitted.

I think you’re talking about running DNS locally (not sure) and resolving .local addresses by DNS. In that case, yes, the devices that do lookups by mDNS will experience a delay caused by first querying mDNS before falling back onto DNS. The solution is to set up mDNS for the internal resources. Using an unregistered domain like .lan has serious security implications. See here: https://serverfault.com/a/17566

.lan is called out in appendix G of the MDNS RFC as "not recommended, but many people do this". Personally speaking, I'm not too worried about .lan getting registered as a gTLD anytime soon. I'm a lot more worried about forgetting to renew my domain and having things horrifically break if/when that domain gets picked up by someone else. This is a lot more likely...

I’m not sure I understand... What would break on your local network if a public domain you own and use only for internal resources is registered by someone else? How is this different from making up a domain name? In both cases you have to set up something to resolve the names to IP addresses on your local network, be it a hosts file or DNS. I would expect that to keep working regardless of the ownership of the domain name.

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

#363

Post by est31 »

est31 wrote: post #248
toast0 wrote: post #165

Earlier quoted context omitted.

Are common certificate validation libraries honoring these constraints? When I tried to use this many moons ago, most things ignored the constraints; although I could mark the extension critical, and then some (but not all, yay) of the things that didn't understand would refuse the CA.

IDK NSS seems to have code to verify it: https://searchfox.org/mozilla-central/source/security/nss/li... As does webpki: https://github.com/briansmith/webpki/blob/482627c40dad2148da... But haven't tested it (or checked other libraries).

Update: tested it with openssl and webpki. both claim to have support but it only works with openssl. For webpki I had to file two bugs:

https://github.com/briansmith/webpki/issues/134

https://github.com/briansmith/webpki/issues/135

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

#364

Post by fomine3 »

kube-system wrote: post #252
elcritch wrote: post #147

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.…

How is that different than how self signed certs work now? My browser warns me, I can accept the warning for that particular certificate, and it warns me again if it changes..

At least for Chrome and Firefox, I can't accept self-signed cert easily for permanently. It asks again if I exited the browser.

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

#365

Post by dimensi0nal »

imtringued wrote: post #346
dimensi0nal wrote: post #76

Earlier quoted context omitted.

A .net is 83 cents a month.

That's usually a limited special offer. Not everyone wants to change domains every year.

https://www.cloudflare.com/products/registrar/

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

#366

Post by kube-system »

fomine3 wrote: post #364
kube-system wrote: post #252

Earlier quoted context omitted.

How is that different than how self signed certs work now? My browser warns me, I can accept the warning for that particular certificate, and it warns me again if it changes..

At least for Chrome and Firefox, I can't accept self-signed cert easily for permanently. It asks again if I exited the browser.

Do you have them configured to clear those settings on exit? Is the certificate actually the same when you visit the site again?

Chrome and Firefox remember the acceptance of self-signed certs for a long time on my PC.

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

#367

Post by yjftsjthsd-h »

GordonS wrote: post #353
yjftsjthsd-h wrote: post #206

Earlier quoted context omitted.

https://zerossl.com/features/acme/ Free, even.

ZeroSSL are a commercial CA... I can't figure out what's in it for them to offer free 90-day certs with auto ACME renewal?

I assume on-ramp/freemium. Free certs help them sell paid certs.

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

#368

Post by jopsen »

dylz wrote: post #324
jopsen wrote: post #303

Earlier quoted context omitted.

Crazy idea: Why not serve an initial page over HTTP, and then implement encryption in JS using webcrypto for all subsequent calls. I'm not sure self-signed HTTPS can do much better than this anyways. (Yes, yes, it's a crazy idea, hehe)

You can no longer do webcrypto because the initial page is compromised. Self signed HTTPS works for this case as long as you know the fingerprint/cert to accept.

Oh, yeah... webcrypto only works on HTTPS.

So you would need to ship a crypto library in JS, hehe :)

Self-signed certs probably does work, if you install the certificate root on your machine. It just not something you would advice end-users to do.

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

#369

Post by dylz »

jopsen wrote: post #368
dylz wrote: post #324

Earlier quoted context omitted.

You can no longer do webcrypto because the initial page is compromised. Self signed HTTPS works for this case as long as you know the fingerprint/cert to accept.

Oh, yeah... webcrypto only works on HTTPS. So you would need to ship a crypto library in JS, hehe :) Self-signed certs probably does work, if you install the certificate root on your machine. It just not something you would advice end-users to do.

The other problem is shipping a crypto library if the entire page and script is not served over HTTPS means that it's no longer useful, because the crypto library is compromised.

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

#370

Post by jt2190 »

xg15 wrote: post #306
gsich wrote: post #110

Earlier quoted context omitted.

Depends on them I guess. If it's a corporate phone then it's no problem. The rest can either add it or get used to cert warnings.

If you're in a context where you can personally install it on phones of friends and relatives, that will work, I agree. I'm thinking of an example to illustrate what I mean. (Sorry if this appears to be moving the goalposts) Imagine some small business is selling a home surveillance camera, or a network printer or whatever else. The thing is that it's a product intended for perivate, layman consumers and intended for…

> This also leaves you with the challange to safely get the certificate to your users.

Because the hardware vendor does not own nor configure the private network, they are not able to certify to the network’s users that a particular network node is the device it’s supposed to be, and not an impersonator. Only the network administrators can do that, and so it is the network administrators that must generate the certificate and install it on the device. In this way the admins bestow a programatic declaration of trust on the network node.

The device manufacturers can only provide tools for showing that the device was not tampered with. TLS/SSL certificates are not for that purpose.

Post reply on HN