Hacker News Reader

Comment by justinschuh | Hacker News Reader

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.

View on HN

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