Live data from Hacker News

Chromium and Mozilla to enforce 1 year validity for TLS certificates

chromium.googlesource.com

231–240 of 375 posts

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

#231

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…

No, I don't. Browsers have always controlled the internet since the web became the dominant way the internet is used. And I'm really quite happy for them to do this because lord only knows helping my various relatives with their computers has proven to me that someone needs too.

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

#232
post #103
post #65

Earlier quoted context omitted.

Buy a domain, create a subdomain for local use, and issue ACME certs with Let's Encrypt every 60 days. If your vendor device or software doesn't support automated certificate rotation, put nginx/haproxy/envoy in front of it.

This won't work either, btw: You'd have to request from Let's Encrypt a new certificate for each individual device . LE has several rate limits that will prevent that from working for anything more than a trivial number of devices: https://letsencrypt.org/docs/rate-limits/ The only way I see how this would work is if you not just purchase a domain but also an internet-facing server and do the renewal and certificate…

The LE rate limits are (mostly?) for new cert issuance. I’ve never run into a rate limit on automated renewals and seem to recall it was either non-existent or comically far away from anything any individual would hit.

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

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

It handles it by asking "Do you want to trust this new server?"

Asking the end user to accept downgraded security is a huge security antipattern.

Also, if I’m operating an evil wifi AP at a coffee shop and I intercept your web request for bankofamerica.com with a redirect to bankofamerica.local, would HSTS prevent the redirect? Or could I then serve you a bad cert and trick you into accepting it?

Also, what sokoloff said makes a lot of sense. Encryption without authentication is worthless, and that cert chain only works in so far as someone at the top vouches for someone’s identity. If that’s your print server, then you are the one vouching for its identity. It makes more sense for you to be the certificate authority and just build your own cert chain.

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

#234

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

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

Because 99.99%+ of users don't have the technical skill to do this, but still need to be able to access local devices and it would sure be good if they could do so in a secure manner?

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

#235
post #98
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…

> Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. CA certificates can be constrained. https://tools.ietf.org/html/rfc5280#section-4.2.1.10

How do you actually generate a constrained CA certificate? I have tried to do this for a long time but openssl is inscrutable.

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

#236

Earlier quoted context omitted.

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

Good to note. But I think you're distracting from the article's talking point.

I disagree with "switch to HTTPS or lose ranking", but that's an HTTP vs. HTTPS issue with Google's search ranking, not about Chromium or Mozilla. This article is about Chromium & Mozilla making stricter rules for HTTPS certificates. That's not a bad thing, to hold HTTPS sites to a better standard.

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

#237
post #102
post #66

Earlier quoted context omitted.

Without buying a domain. (and continously spending money to keep it owned)

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 meaningful only on the link where they originate. [...] Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).

I'd recommend using something like .lan instead.

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

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

Do self-signed certs not work? Yes, you have to tell your browser to permanently accept them the first time you connect, but after that, they work.

Chrome seems to intentionally forget you accepted self-signed certificates after some period of time.

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

#239
post #229

Earlier quoted context omitted.

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?

Because he might be a user too.

And are you blocking all Web traffic except from people who your users, somehow? If not, then everyone is your user.

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

#240
post #229

Earlier quoted context omitted.

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?

I don't really understand your point. You're upset because I am advocating for your users despite not being one? I... don't care at all.

It isn't my business so I've done nothing to reach out to your users or interfere in your website. We're having a discussion about technology on a technical forum.

It is the browser developers' business though since they are tasked with protecting users from these specific threats.

Post reply on HN