Comment by da_chicken | Hacker News Reader

Comment by da_chicken | Hacker News Reader

Parent Full thread

Eh, kind of. It's successful as far as the Internet, which is great. But Internet web pages isn't everything.

There's still a real issue with infrastructre that has web configuration. Everything from home routers to video cameras and so on. Not being able to ship with a certificate that passes browser security checks is a problem that essentially nobody has addressed.

When people connect to an IOT device, they need to be able to connect with a web browser and not jump through hoops to say, "No, really I know that this is a secure connection." Because we can't keep teaching people to dodge secure connections when they should care about having secure connectinos. As much as I don't like IOT, but this is an issue that needs to be easier than "understand cyrptography configuration, generate your own keys, and install them wherever you need them".

That's all besides the vendor "solution" of "install this phone app that will maybe barely work except for the parts that track your data forever LOL thx sucker".

Right, but that's not HTTPS Everywhere.

HTTPS Everywhere was "this site already has HTTPS, and really should only use that, but doesn't, so we'll redirect you to the HTTPS version". Now sites that have HTTPS default to it, and browsers have options to basically try https first and see if it works.

Should have been called "HTTPS as long as its already there".

"HTTPS Everywhere" is pretty suggestive. And the English meaning of the words might be a worthwhile goal too.

What more would you expect of a browser plugin?

Was there any confusion about the plugin creating an HTTPS capability where one doesn't exist? I always understood the outcome to be very clear.

Couldn't browsers just designate the .local tld to not check for SSL certs and enforce that it resolves to an IP on the current network? Seems like a simple solution for this.

How do we define 'current network'?

That's a thing for local software to decide.

It's also something that can be done with a level of reliability that will impress incredulous people. But that there will always be somebody to complain that is not following the standard recommendations.

In that case you don't need a certificate. Just check that the .local FQDN's IP is on a local network.

  1. Look up all local interfaces' networks (IP & subnet mask)
  2. Determine if .local IP is within subnet range of one of the interfaces
  3. If .local IP is not on a subnet of a local interface, drop the connection

This is still "host-based networking" and there's always the possibility a rogue network could be attached to your host, such as a spoofed open access point, or an ISP with lax network security and a customer on the same subnet being attacker-controlled.

What certs prove is "this host currently has a private key and cert, and at one time this private key was used to generate a CSR for this cert, and at one time it was validated that an IP resolvable by the domain name in the CSR was also controlled by whoever issued the CSR". It's a very awkward thing that doesn't really match up to local consumer devices.

We need a vendor key registry, the way MAC address prefixes are mapped to vendors, so at least we could say "the key on this host came from vendor XYZ". The browser would need to pop up a warning saying "WARNING: You are now connected to a local device from Vendor XYZ! If you did not intend to connect to a local device, close this window!" Updates to the vendor registry could also invalidate previous entries if old keys got compromised. But this would be in combination with the aforementioned "is the site on a local network?" logic. Anyone using a .local would have to both compromise a local network and steal a key from a vendor, or be registered as a vendor, and then the user would have to be dumb enough to click through a big warning about a local device.

Indeed that's much better.

It's probably better if we terminate the trust at a TLS certificate or something similar to DANE. So there isn't any specialized registry to maintain.

It's not practical to hide vendor keys. Unless the key is embedded in a security chip in factory it's usually possible to extract them from the firmware. Even if vendor CA is not compromised, stealing keys from a single device should be sufficient.

I was thinking more along the lines of signature verification, but I forgot that any spoofed device could just supply a signature it got out of a device, so I think you're probably right.

I wonder if the router or switch could be set to provide that information? Most modern routers have LAN info and could reliably inform a smart enough appliance that it is accessing something inside of the gateway address.

Lots of local devices already do such a lookup and there's a whole class of vulnerabilities based on it (DNS rebinding and friends).

I'd personally classify 192.168/16, 172.16/12, 10/8, 127/8, fe80/10, and ::1 as local networks, but that's simply not always the case. There are tons of universities and even business out there that use publicly routable addresses for clients and that approach is even the default for IPv6. You could be tempted to use the local network range as a "local" network but there are plenty of networks out there where that would mark foreign networks as "local". Then there are those who use 1.0.0.0/8 for local addresses because that subnet was previously unused and the 10 range already had a separate meaning.

Just verifying that .something (.local is already reserved, you shouldn't use it for internal device names even though it'll probably work) matches an internal IP doesn't add any security. You might as well mark HTTP to local IP addresses as a secure origin and not mess with certificates at all. I don't th9nk that's a very good idea.

With IPv6, there's a solution to this problem. You can provision certificates to globally unique IP addresses and possibly their hostname. I don't think there's a solution for IPv4 on most local networks, though.

But .local is reserved for mDNS. The correct suffix for hostnames on a home network with nothing better configured is actually ".home.arpa".

However precisely because .home.arpa domains are non-unique is is forbidden by the relevant RFC to treat it specially for security. Because with a roaming device, when out on say an public attacker controlled wifi, the name might resolve to something malicious under attacker control, and doing something automatically trusting self signed certs would make it more likely that attacks using such devices could succeed.

If a mechanism for securely identify exactly which home network you are connected to is eventually discovered, then this limitation can be lifted, with the user specifically whitelisting trusted home networks.

It's security theater, it's not meant to solve real problems for real people.

Since everyone is using HTTPS, the problem has been away for so long that you simply forgot it.

The year 2015 wants its flamewar back.

I was thinking about this classic article [0] that gets linked whenever people talk about HTTPS?

If so, that's a 2017 flamewar.

[0] http://n-gate.com/software/2017/07/12/0/ (NOTE: this site tracks if you come from HN and sets a cookie. You'll probably need to open it in incognito)

Reply on news.ycombinator.com