Hacker News Reader

Hacker News

Comment by jand | Hacker News Reader

Parent Full thread

jand

Enumeration and more - as far as i understood.

My evil website can no longer access the top secret stuff you are developing on localhost.

My evil website can no longer enumerate the http servers in your local LAN.

View on HN

"This website would like to scan your local network and communicate with other devices" "Allow Once/Deny/Block"

Well maybe I want to grant the site access to a particular internal IP without the ability to send requests everywhere... at what point would Chrome just have its own separate firewall?

The modern browser is already an operating system by all definitions I know so yes, it might as well have a firewall.

But that isn't very elegant, so I propose version 2.0:

"This site has requested communication with a local device. Please select it from this list:"

[the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page]

Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec:

> window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked.

[0] https://www.w3.org/TR/2012/WD-discovery-api-20121004/

The problem with that is the site the user is on is http:// . Security at that point is pretty iffy. You kind of need to say "foo.com or some MITM attacker pretending to be foo.com wants to scan your local network. Allow Once/Deny/Block".

Full disclosure I work at Google, but not on Chrome.

Of course that would be a problem, but that simply isn't the case. It certainly wasn't the case for Portal or any other site I've seen that used this feature. Limiting this to only secure contexts would solve your problem and is what Google is technically doing. The issue is that requests from HTTPS->HTTP sites in aren't allowed either ("Mixed Content") and so effectively, Chrome is disallowing ALL public->local requests, since HTTPS on a local site is broken by design.

> If your website needs to issue requests to a target server on a private IP address, then simply upgrading the initiator website to HTTPS does not work. Mixed Content prevents secure contexts from making requests over plaintext HTTP, so the newly-secured website will still find itself unable to make the requests.

The solution, of course, is clear to the Chrome devs - certificate pinning. Unfortunately, they implemented it in an absolutely ridiculous way that limits you to WebTransport for absolutely no other reason other than they want to force developers to use it as soon as possible before the other browser vendors (*vendor) implement it. As I mentioned in a sibling comment, there is absolutely no reason to not simply add a "CACert" option to XHR,fetch,WebSocket... and let developers use the existing protocols.

>It certainly wasn't the case for Portal or any other site I've seen that used this feature.

What do you mean? The only change Chrome is making is limiting it from http:// sites. If Portal is saying Chrome is breaking them, then they must have been making connections from http:// sites. The mixed content limitations have been there for a long time already, which must be why they were using http:// . I've never used Portal myself so I don't have direct evidence they were using http:// , but this is the only logical explanation I can come up with for why they would say Chrome is breaking them.

https://developer.chrome.com/blog/private-network-access-upd...

Reply on news.ycombinator.com