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

271–280 of 375 posts

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

#271

Post by Spivak »

paledot wrote: post #213
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

There are two options: * Manually install a root certificate, which is a confusing process for most end users and a non-starter for anyone who cares about security. (Imagine walking your parents through the process.) * Trust a self-signed certificate, which is an increasingly difficult and counterintuitive process since Chrome and Firefox started competing to see who could destroy their usefulness faster. I'm not eve…

I mean I’m not sure if there’s a solution that will make everyone happy then. Making trusting self-signed cheers easy and not scary has real security implications because users just click-through warnings.

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

#272

Post by superkuh »

j1elo wrote: post #257
superkuh wrote: post #244

Earlier quoted context omitted.

This is exactly the same as blaming getting shot at a neighbor's BBQ on the neighbor for not hiring private security to deal with the government army specifically attacking you. If your threat model includes nation state attacks you're gonna have problems no matter what. Change your personal behavior accordingly. Don't tell everyone else they need to wear bullet proof vests around the house and hire corporate securit…

You're right, today . But as everything, stuff that starts as very advanced tools only at the disposal of big agencies, with time ends up being reachable for more mundane users, or in this case, criminals. So, in a way, it's probably just a matter of time that the kind of silent hack depicted in the Amnesty article is used for attacks targeted towards more general victims. I don't look forward to the day that just by…

I know complaining about it won't change the future course of things but these are all problems coming from treating the browser like the OS and exposing more and more low level functionality.

They aren't problems with security in HTTP versus HTTPS for a personal or small business static website.

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

#273

Post by mholt »

AlfeG wrote: post #261
dingaling wrote: post #259

Earlier quoted context omitted.

Giving an Internet-connected program autonomous write-access to system-critical filesystems is not considered good practice in production environments. Much better to have a separate central cert management system that handles renewals and pushes the certs outwards to the DMZ systems.

This is true for enterprise, but for small business Caddy or Traefik is totally fine.

Caddy is good for enterprise use too because of its configurable, pluggable storage backends (doesn't have to be a file system). You can achieve the permission segmenting your company requires.

You can also use it as a certificate manager independently of a web server if you want.

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

#274

Post by drdaeman »

CountSessine wrote: post #250
sukilot wrote: post #246

Earlier quoted context omitted.

If the browser correctly explained what you were doing, and warned you that this is an attack unless you are in control of the entire network and the machines on it, I don't see the problem.

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 browser vendor would implement something like this (denoted by a special OID on the certificate), IoT vendors would be happy to follow. Verifying a phrase or scanning a code is not a big burden, and it resolves trust issues.

The fingerprint could be either from a private key generated on device (for devices that have a display and can display dynamic content) or from vendor's self-signed "CA" with special critical restrictions (no trust for any signatures unless individually verified + signed certs are only valid on what clients consider to be a local network) which private keys are not on the device itself (for devices with printed labels, to avoid having the same private key on all devices).

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

#275

Post by riskable »

filmor wrote: post #258
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.

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.

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

#276

Post by majewsky »

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…

You can always issue the TLS certificate on an internet-facing system that can do the corresponding ACME challenge, then give it to the internal service and have all clients of that service resolve the domain name for the certificate via a static configuration in /etc/hosts. That's how I do TLS for my intranet-only LDAP server.

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

#277

Post by petronio »

sukilot wrote: post #247
petronio wrote: post #242

Earlier quoted context omitted.

A lot of the devices mentioned ("routers, printers, and self-hosted IoT devices") don't give ways to change the certificate. Besides, not every individual or company wants to or is knowledgeable enough to manage their own CA. For the audience in HN it might be an hour one evening, to others the instructions read like black magic.

Routing is scary magic. DNS is scary magic. Wifi is scary magic. Everything in computing is scary magic until someone writes an app with good UX for it. It's not a fundamental problem.

It is a fundamental problem, because you need specialized knowledge to understand what is being presented and asked of you in the UI.

The average user knows absolutely nothing about routing, most will throw their hands up or their eyes will swim if you so much as mention something like IP address.

They also know nothing about DNS and don't have to: because we always give them defaults that they never see and they go along with their lives.

As for wifi, once again, largely automated. Most people never change the default SSID and password. There's some manufacturers that will make a good UI, but it stops at the SSID and passwords because that's the extent of most users' understanding. Some users have a vague understanding that 2.4GHz and 5GHz is different, but don't know the significance of the difference. Channel, authentication type, and other options aren't given to users in those UIs because they simply wouldn't know what to do with it and people don't read manuals anyways.

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

#278

Post by Almad »

kspacewalk2 wrote: post #39
Almad wrote: post #20

Internet starts to have 1y memory retention. Unless refreshed by active learning, aka someone doing the refresh job. Or unless delegating the work to large players—either the memory or the hosting. EDIT: This feels wrong, even when done for right reasons. And I wonder whether this would fly without LE and whether this means we are officially making LE THE critical part of Internet infrastructure.

Websites marked "insecure" are still fully accessible.

Not always. You may also end up with having incompatible set of ciphers (happened to me).

"Get off my Internet lawn if you can't be up to date" is what we're saying and I just do wonder whether we haven't exchanged too much of accessibility for too little of security.

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

#279

Post by Spivak »

Karunamon wrote: post #227
rad_gruchalski wrote: post #173

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.

But this is silly. If this isn’t completely trivial to add to your app then something has gone horribly wrong.

* Every machine in your infra already has backups, right? Nothing about your signing boxes are special in this regard.

* All your services are already HA, right? The API servers that now have to run some glorified OpenSSL commands aren’t any different than your normal API endpoints.

* You already have to protect secrets on your machines. DB passwords, API keys. What’s one more?

* You don’t have to implement ACME. These are your devices talking to your devices.

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

#280

Post by majewsky »

gruez wrote: post #198
floatingatoll wrote: post #40

Earlier quoted context omitted.

A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.

> you're probably also in a position to block the CRL response from going through

Not if the certificate is OCSP-Must-Staple.

Post reply on HN