Hacker News Reader

Comment by rcxdude | Hacker News Reader

It's a pretty bad one, though. It massively undermines the security of connections to local devices for a slight improvement in security on the open internet. It's very frustrating how browser vendors don't even seem to consider it something worth solving, even if e.g. the way it is presented to the user is different. At the moment if you just use plain HTTP then things do mostly work (apart from some APIs which are somewhat arbitrarily locked to 'secure contexts' which means very little about the trustworthiness of the code that does or does not have access to those APIs), but if you try to use HTTPs then you get a million 'this is really inesecure' warnings. There's no 'use HTTPs but treat it like HTTP' option.

View on HN

Either you really are secure, or ideally you should not be able to even pretend you are secure. Allowing "pretend it's secure" downgrades the security in all contexts.

IMHO they should gradually lock all dynamic code execution such as dynamic CSS and javascript behind a explicit toggle for insecure http sites.

> It massively undermines the security of connections to local devices

No, you see the prompt, it is insecure. If the network admin wants it secure, it means either a internal CA, or a literally free cert from let's encrypt. As the network admin did not care, it's insecure.

"but I have legacy garbage with hardcoded self-signed certs" then reverse proxy that legacy garbage with Caddy?

I'm talking about situations where you have nontechnical users that need to connect to the device, neither the client nor the device have necessarily an internet connection, and the connection is often via a local IP address. None of your proposed solutions are appropriate for that situation. And basically all I'm asking is that the connection be at least encrypted (meaning that eavesdropping is not enough: you need to construct a man in the middle), even if it's not presented to the user as secure.

(An option to get some authentication, and one that I think chrome have kind of started to figure out, is to allow a PWA to connect to a local device and authenticate with its own keys. This still means you need to connect to the internet once with the client device, but at least from that point onwards it can work without internet. But then you need to have a whole other flow so that random sites can't just connect to your local devices...)

How often are you offline like that but on a network you can trust isn’t malicious? If I’m at home, my printer is more protected from eavesdropping by the WiFi password than a self-signed certificate. If I’m at the coffee shop, it’s insecure because I can’t trust the dozens of other people not to be malicious or compromised, and the answer is to clearly tell me that it’s unsafe.

You could be in any of those situations, is my point. I fail to see any situation where some encryption is worse than no encryption.

I don't think it's correct to say that browser vendors don't think it's worth solving. For instance, Martin Thomson from Mozilla has done some thinking about it. https://docs.google.com/document/u/0/d/170rFC91jqvpFrKIqG4K8....

However, it's not an entirely trivial problem to get it right, especially because how how deeply the scheme is tied into the Web security model. Your example here is a good one of what I'm talking about:

> At the moment if you just use plain HTTP then things do mostly work (apart from some APIs which are somewhat arbitrarily locked to 'secure contexts' which means very little about the trustworthiness of the code that does or does not have access to those APIs),

You're right that being served over HTTPS doesn't make the site trustworthy, but what it does do is provide integrity for the identity of the server. So, for instance, the user might look at the URL and decide that the server is trustworthy and can be allowed to use the camera or microphone. However, if you use HTTPS but without verifying the certificate, then an attacker might in the future substitute themselves and take advantage of that camera and microphone access. Another example is when the user enters their password.

Rather than saying that browser vendors don't think this is worth solving in the abstract I would say that it's not very high on the priority list, especially because most of the ideas people have proposed don't work very well.

I'm pretty sure private PKIs are an option that is pretty straightforward to use.

Security is still a lot better because the root is communicated out of band.

Reply on news.ycombinator.com