Hacker News Reader

Comment by stefan_ | Hacker News Reader

So, what is the Chromes team solution for local network devices like routers? Proxy it over the manufacturers server for a complete loss of any privacy and security, but hey, there is a green check mark then?

View on HN

This change will only add the grey 'not secure' text to the address bar and not hinder functionality. So it is just less green and not more red as with invalid or self-signed certificates where you have to perform additional steps to continue.

That's in this version. How many versions until we get the ridiculous harassment already required for self-signed certs?

The older blogpost that laid out the roadmap stops here. https://security.googleblog.com/2016/09/moving-towards-more-... It's not impossible that they would do that in the future, but their plans so far don't seem to include that.

There are already https only features, and their number will probably just keep increasing

https://www.digicert.com/blog/https-only-features-in-browser...

https://www.chromium.org/Home/chromium-security/deprecating-...

https://blog.mozilla.org/security/2018/01/15/secure-contexts...

I can only agree with that. Having security contexts as a formal concept and requiring secure transport for certain features. Stuff like webcam or other hardware access (bluetooth) should really not be allowed from a insecure (MITM'ed?) source.

For now..

Look at the trend. First it was just a small SEO bump.

The problem is really _naming_ these devices first of all. If they have (global) names there's no problem to issue a certificate for those names.

But so often the device doesn't have any name at all, so it's maybe 10.0.0.1, and so is everything else, the problem only appears to be in the security layer because that's the first place which absolutely insists that you can't have a situation where everybody is just named "Bruce" with no other identifier.

Where it does have a name, the name is often not part of the global namespace. At least here we can fix that with a namespace suffix. Sold five million routers with serial numbers? Name them $serialnumber.routers.your-company.example and problem solved. Now that they have a name, issuing them certificates isn't difficult.

(Yes, a commercial vendor who'll hook you up with five million certificates won't do it for free. The little rubber feet and the half-arsed English translation of the instruction manual weren't free either. Too bad)

That assumes your DNS is running through the device itself. For a router, maybe, beyond that, not really.

I don't know why there is still no standardization for advertising/providing CA services for local networks. How difficult would it be to just put local ACME endpoint to DHCP options?

adding a local CA means you can middleman anything you want to, seems like something that should be difficult to do, to me.

Name constraints are a thing. Local CA should be constrained to signing only local names (roughly matching dhcp domain-name/domain-search options).

Name constraints are not universally supported in browsers sadly.

And this should be fixed. Name constraints would be incredibly useful for a number of things, if only they were supported.

I believe Apple is the holdout in this case, meaning Safari and Chrome on MacOS don't support it.

ACME has nothing to do with provisioning root certificate trust stores and I hope DHCP never will either. If you need additional local root CAs then deploy them via enterprise workstation management solutions.

But then what’s the point? How is it more secure to have anyone get a server cert automatically without credentialing. Not to mention training users to trust all the BS local CAs popping up now that can then MITM traffic.

As a user, I don’t want local networks setting me up to make me recognize their CA services.

At first I liked SSL everywhere, but now I’m seeing a lot of hacks that are going to make SSL less useful.

Not to mention training users to trust all the BS local CAs popping up now that can then MITM traffic.

You say that as if users don't already mindlessly dismiss most warnings already. I'm not convinced this would be that big of a difference from the current system.

This sounds great acually. Browsers should only trust them when connecting to local IPs (based on subnet or something), is displayed as a gray padlock that says "Local", the ACME endpoint should be restricted to only giving out certs on specific domains (.local or something), and to reissue any cert with the same name as a previous cert the device has to prove that it's the same (unique embedded public key or something). Maybe an exception that devices can always get a local cert for its IP, and the owner of the ACME device can assign "pretty" names to "unique" names on a case-by-case basis.

The thing issuing DHCP leases has full control over your ability to connect to the internet anyways, so around here seems like the right place to put it.

My only qualm is that I trust router manufacturers to implement this correctly about as far as I can throw a sheet of paper.

do many routers not support https for their config pages? if so, that's terrible on their part, get a new router. If they do, then accept the cert in your browser and move on.

The Ubiquity routers use a self signed certificate, which Chrome already marks as insecure. There's ways to change it to use Let's Encrypt though.

Adding this cert to your trusted certs file marks it as secure, even if self-signed. This is better than usual.

Most consumer routers use self signed certificates which will be marked as insecure by the browser.

All modern browsers allow you to import certs into their trust store.

But the UIs for that is actively discouraging people from doing so.

Besides, I believe, the majority of people using router config page wouldn't even know for sure what 'importing certs into their browsers trust store' means or why it should be done and where those certs are etc. There's a ton of consumer-unfriendly terms and concepts, plus, as the parent noted, the UIs are usually discouraging.

That's exactly the problem. Devices in the local network can not partake in the public CA infrastructure. So they run self-signed certificates, which is probably a small security win over plain HTTP, but then customers are faced with a scary "someone is stealing your data" page before ever seeing the configuration page. That's a no go, so most stay on HTTP, but as we can tell from this announcement, time is running out for that. Leaving them with zero good options.

If this trend continues it means you will no longer be able to configure these devices with a webbrowser but forced to use the manufacturers "cloud solution" or install an app where both ends of the TLS connection can be controlled and you're not bound to public CAs.

I think you are jumping to conclusions for no good reason here, I think it's absolutely unlikely to happen that browsers remove http support. Worst case they'll add a clickthrough screen similar to the invalid ssl interstitials of today. Surely you can deal with an extra click through when logging in to your wifi router if you can't be bothered to install an ssl cert for it?

I can deal, but we're looking for the Dropbox solution here. This is only going to become worse with all the IoT hype, and if it's not solved, it will just mean all these devices will go through the manufacturer, all the time.

I bought a Uniquiti AMPLIFI home router. It’s great for signal, but can only be administered through their app (all traffic through their cloud, etc). This really sucks and they don’t really care as it’s probably easier to dev and they get all that sweet usage data.

It’s not a good trend, but this is a plus for most consumers who don’t care about local network security.

Amplifi should be manageable through UNMS by the end of the year or so. I cant seem to find the chart, but here is an image from the forums: https://usercontent-community.amplifi.com/461f0130-9835-459b...

That will be good. I almost bought their enterprise stuff because their signal is so good.

Reply on news.ycombinator.com