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

221–230 of 375 posts

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

#221

Post by staticassertion »

DenisM wrote: post #203
staticassertion wrote: post #148

Earlier quoted context omitted.

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…

If I was the bad actor I would simply purchase google ads in the name of the target business sending traffic to my own site with wonderful green padlock - it's cheaper and has bigger reach than trying to hijack TCP/IP traffic. More to the point - if I am running a collection of Karl Marx works it is highly unlikely that he would request payments.

You're describing a completely different attack vector, which is the entire point - to push attackers to different attacks. if we eliminate HTTP, we can focus more effort on the attacks you're describing.

Regardless of the content, hijacking is a danger to users.

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

#222

Post by brian-bk »

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

It's not wrong to build whatever you want for yourself.

But if you have external users on your site sending data to your site, you have a responsibility to not treat your users' data as meaningless.

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

#223

Post by zozbot234 »

loeg wrote: post #211
arwineap wrote: post #195

Earlier quoted context omitted.

> It handles it by asking "Do you want to trust this new server?" That's basically how it works though; your OS packages a group of trusted CA certs. You can add additional trusted CA certs, even ones minted by you to ensure your apps trust the connection

The mechanism SSH uses is called Trust on First Use ("TOFU") and is closer to what used to be HTTPS certificate pinning. In this scheme, certificates never expire, and if they do, clients warn about the unexpected change in certificate. It is different from the CA PKI system, where the client trusts any certificate signed by a trusted CA without prompting the user at all, and doesn't prompt the user if the certificat…

Self-signed certificates give you basically this. It's a bit of a hassle to mark them as trusted, but you only have to do it once.

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

#224

Post by maxmalysh »

brian-bk wrote: post #218
maxmalysh wrote: post #37

Earlier quoted context omitted.

http://www.paulgraham.com/

There's no cert because there's no need for one in the first place. Mentioning that is pretty silly - it's obvious that there's nothing wrong with a static site with now cert, and no one is arguing against that.

> there's nothing wrong with a static site with no cert

Not really. Google says "switch to HTTPS or lose ranking":

https://webmasters.googleblog.com/2014/08/https-as-ranking-s...

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

#225

Post by toast0 »

gruez wrote: post #207
toast0 wrote: post #179

Earlier quoted context omitted.

If you accidentally leave DNS pointing at an old IP that gets recycled to someone else, you've authorized LetsEncrypt to issue a certificate to the lucky winner. Most old school CAs do domain validations against the root of the domain, so it's a lot harder to accidentally delegate that. That's not a reason not to use LetsEncrypt, but it's a reason not to include it in certificate pinning.

> If you accidentally leave DNS pointing at an old IP that gets recycled to someone else, you've authorized LetsEncrypt to issue a certificate to the lucky winner. Yeah, but only for that particular subdomain. Sounds like a pretty contrived attack. For it to work, it needs to be some website that you forgot about, but still have enough users that it's viable to attack it. >Most old school CAs do domain validations ag…

> Yeah, but only for that particular subdomain. Sounds like a pretty contrived attack. For it to work, it needs to be some website that you forgot about, but still have enough users that it's viable to attack it.

Not really, something similar happened recently (forgot the company details but was discussed on HN). Somebody left dangling DNS pointed at AWS, new IP holder was apparently using domain scoped cookies / etc to grab browser data. Of course, cert pining in browsers is largely dead, so not a lot an average person can do here (other than not f* up their DNS). Larger entities can still get one off cert pinning by emailing chrome/other browsers.

>> Most old school CAs do domain validations against the root of the domain, so it's a lot harder to accidentally delegate that.

> Source for this? If there's even a handful of paid CAs that validate at the subdomain level this is a moot point.

This was from personal experience, could be obsolete. But if you're pinning to a couple of commercial roots, you only need to confirm that those roots don't issue certs from subdomain authentication.

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

#226

Post by sokoloff »

elcritch wrote: post #147
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.…

Why do you need to use self-signed certs? (As contrasted with CA-signed certs that happen to be signed by a CA that you own and trust as suggested by arwineap?)

It took my a little over an hour one evening to figure out how to create my own CA, trust it, and sign certs for all my local devices (except my UniFi cloud controller which I admit I gave up on due to time).

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

#227

Post by Karunamon »

rad_gruchalski wrote: post #173
geerlingguy wrote: post #99

Earlier quoted context omitted.

> This is a ridiculous requirement that is not at all practical.

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.

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

#228

Post by toast0 »

namibj wrote: post #174
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.

Can you name and shame those that ignored the critical extension? Sounds CVE-worthy. A date to guess the versions you used would also help.

No, it was on the order of 5 years ago; everybody was garbage back then. But, if this had become usable, I would expect to have seen articles about using it since then.

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

#229

Post by DenisM »

staticassertion wrote: post #221
DenisM wrote: post #203

Earlier quoted context omitted.

If I was the bad actor I would simply purchase google ads in the name of the target business sending traffic to my own site with wonderful green padlock - it's cheaper and has bigger reach than trying to hijack TCP/IP traffic. More to the point - if I am running a collection of Karl Marx works it is highly unlikely that he would request payments.

You're describing a completely different attack vector, which is the entire point - to push attackers to different attacks. if we eliminate HTTP, we can focus more effort on the attacks you're describing. Regardless of the content, hijacking is a danger to users.

It's worrisome that you injected yourself into the conversation between me and my users. How is this any of your business?

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

#230

Post by CydeWeys »

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…

I'm surprised to see this as the highest comment on this post.

This is a clear security win, and thus good for users. And no, I don't trust websites to have my best interests in mind, not remotely. Hell, if browsers hadn't started warning about insecure connections then I suspect that even to this day most websites would still be insecure. We used to leave it up to the choice of each website, and that was a clear failure, and now they're being forced to provide better security, which is a clear win.

Post reply on HN