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

301–310 of 375 posts

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

#301

Post by elcritch »

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.

The identity isn’t trustworthy, but as mentioned below their are ways to handle that with device id’s. Also it’s not pointless to encrypt communication with a device you’ve verified the identity of in the past. It prevents hijackers from later hijacking the device, without The user knowing it. Just the same as the nastygram you get when your ssh server changes its private key.

You’re effectively claiming SSH is pointless and/or useless encryption as it doesn’t use certificate chains to verify url/domain. Your argument is the same as saying that any devops ssh’ing into a new local server is pointless and they should just use telenet.

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

#302

Post by frutiger »

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

> (Edit: RFQ, not my autocomplete’s RTF)

Sorry for the mostly insubstantial comment but it may help you in the future: it’s RFC (Request For Comments) not RFQ.

And it’s IETF (Internet Engineering Task Force) not ITEF.

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

#303

Post by jopsen »

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

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)

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

#304

Post by chongli »

dingaling wrote: post #256
cpach wrote: post #55

Earlier quoted context omitted.

As long as you first create a root certificate then you can create how many certificates you want.

Assuming non-chained root CAs remain trusted. I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.

Then people will create their own root CA and use it to sign the existing root CAs. Whatever it takes. Corporate users need internal certificates.

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

#305

Post by paledot »

ithkuil wrote: post #295
drdaeman wrote: post #274

Earlier quoted context omitted.

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

That works fine with a brand new device you just unboxed. But what should happen 3 years later? Should the IoT device have a certificate that is valid forever?

I would say yes, as long as certificates are unique per-device. The harm of my light bulb's cert being compromised is less than the harm of my light bulb no longer working if the manufacturer's CA goes offline and it can't renew its cert.

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

#306

Post by xg15 »

gsich wrote: post #110
xg15 wrote: post #105

Earlier quoted context omitted.

Will you also add it to the iPhones of other people that would want to use the device? (Or more realistically, would they let you add it?)

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

With HTTP, you could add a local web server as a simple way to manage the device pretty easily: Just open a server, communicate the IP address to the user, done. No internet connection required, no continuing support from the company required. Even if the company went bust, the existing units continued to work and the web interface stayed accessible.

There seems to be no good way to replicate this with HTTPS. The closest seems indeed to be a custom root CA - however, then you need to communicate to your users how to install the CA certificate on their own devices, clicking through all kinds of scary warnings and dismissing "this section is for admins only" notices. I predict that not a lot of people would do that.

This also leaves you with the challange to safely get the certificate to your users. You could serve the certificate from the device over HTTP - however, then you'll require that your customers download a root certificate, over an unencrypted connection without any integrity checks and install it on their device. This seems like ripping open a mojor security hole.

Meanwhile, even if the company purchases a domain and attempts to get a certificate from a public CA, deployment will be difficult as described in all the other branches of this thread.

In short, I think you can pick any three of the following four conditions, but I see no way to archieve all four at the same time.

(1) use modern web features (all recently added and all future features require https)

(2) have your site usable on a client device that does not belong to you

(3) present a non-confusing user experience (no cert warnings, etc)

(4) have the device stay accessible even after you stop actively supporting it (by purchasing domains, running cloud services, having deals with CAs, etc etc)

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

#307

Post by elcritch »

Spivak wrote: post #271
paledot wrote: post #213

Earlier quoted context omitted.

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.

That’s why self-signed and "local signed" should be distinct concepts, IMHO. The .local domain is already special cased, and could provide a different UI path more akin to how SSH works. AFAICT, you can’t get a https cert for a .local domain, so it’d not break existing https security model. It’d provide a more secure way for apps like syncthing to provide a secure local UI as well. Getting browsers to accept my self-signed certificate is a pain and makes people just use http.

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

#308

Post by yjftsjthsd-h »

at_a_remove wrote: post #282
yjftsjthsd-h wrote: post #200

Earlier quoted context omitted.

We have had this conversation to death: https://doesmysiteneedhttps.com/

I find some of the arguments on that page, uh ... unhelpful at best. Circular, even.

I guess I could see that for a small subset of the arguments presented, but that leaves all the rest. Honestly, "There's nothing sensitive on my site anyway." covers 90% of arguments I've seen against HTTPS and that answer is strong. The presence of weak arguments doesn't undermine the strong arguments.

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

#309

Post by j1elo »

superkuh wrote: post #272
j1elo wrote: post #257

Earlier quoted context omitted.

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.

Totally agree. The current situation with the complexity of browsers is crazy. Its implications are spoiling all around other technologies and causing all sorts of issues, like this one.
Post reply on HN