Comment by justinschuh | Hacker News Reader

Comment by justinschuh | Hacker News Reader

I filed this bug (along with http://crbug.com/458362), and there's a bit of context that may be missed. First, this is to protect weak devices and services on private networks or localhost, that really can't be safely exposed to attacks pivoting from the web. It will block only sub-resource loads and navigation from the web to private networks. Navigating directly (via bookmarks or omnibox) or in the other direction (from private to web) is still fine. Essentially, this is applying similar rules to what's already in place for file URLs.

We also appreciate the concerns for legacy apps, local servers, etc. That's why we plan on supporting blocking UI overrides, opt-in by the page on localhost/private (maybe via CORS headers), and permanent exceptions via the command-line and enterprise policy. So, there might need to be some small tweaks, but all the use cases I've seen described in this thread should still work in a portable manner after these changes are made.

Also, to my knowledge no one is actively working on these changes yet. Hence why the details in the bugs are still a bit nebulous. Although that is likely to change pretty soon.

> That's why we plan on supporting blocking UI overrides

By that do you mean, an in-browser prompt to allow the connection?

Pretty much. It would probably be an interstitial on navigation (similar to how certificate errors are handled) and a page action for subresources (similar to the shield page action for mixed content).

It's great to block access to http routers on localhost, which I think was the original point of the bug.

But it's essential that access to secure websocket on localhost not be blocked in the process (which appears to be the case is it stands).

That's the reason for posting here in the first place.

As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the kind of attacks we're trying to prevent.

WSS already has explicit opt-in in the Origin header.

That's not the way the origin header works. The origin header in websockets is provided from the client to the server, and the server must take overt measures to protect itself or scope origins that are allowed. Given that we're worried about unsafe servers, the origin header won't protect against the attacks we're seeing. What we need is a mechanism for the server to authorize the client explicitly, so that we can disallow the resource implicitly when authorization is not present.

Have you seen any attacks on WSS servers on localhost with both explicit opt-in (via the Origin header) and implicit opt-in (via public DNS record and TLS certificate for that public DNS record) and additional mutual authentication (as in the case of Dropbox)? I doubt there are even a handful of people who have setup something like that (I used to think that WSS on localhost was not even possible because of the self-signed certificates not validating).

And that is a specific scenario for which you can easily create a permanent exception for, without requiring the user to start Chrome with a command-line flag.

You can block WS on localhost by all means.

But blocking WSS on localhost after someone has gone through all the trouble of setting up a public DNS record, and CA-signed SSL certificate which validates against that FQDN (this is not just about public DNS localhost record services) makes no sense to me, and seems to be outside the intent of the original bug ticket.

I'm sorry, but I don't understand the argument you're making here. I've already explained that we plan to provide a portable mechanism for private and localhost opt in. It's just not going to be the mechanism you propose, since that mechanism doesn't address the vulnerabilities that we're concerned about.

To reiterate the issues with your proposal: Public DNS pointing to private/localhost is in fact a component of many of the attacks we're concerned about. HTTPS on localhost doesn't do anything because the transport is already secure (which should be simplified in a future change in Chrome's content handling). And given that the major concern is weak/permissive servers, we can't rely on the WS(S) server implicitly protecting itself by enforcing the origin header.

If there's no standard currently in place for this maybe Google's time would be better spent drafting one and going through the RFC process. A single app fix doesn't seem to do a lot of good since the solution for dealing with it is proprietary and not likely to be picked up by other browsers.

Uhm? Unsafe servers? How so? For me it looks like the ticket is about unsafe pages trying to mess up with innocent local services, like router http control panel. WSS origin is exactly what's needed here.

With the server being already running and meant to be connected to from a browser (as combination of WSS and proper localhost cert is proving), listening and explicitly allowing the client to connect, what threat is supposed to be there?

Reply on news.ycombinator.com