Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.
How does this work? Do I have an SSL certificate on my computer for www.dropboxlocalhost.com? Where does the SSL termination happen?
in the dropbox app. Feel free to extract the certificate and MITM connections to your local machine.
Then I'm not entirely sure I understand the point of having an SSL certificate in place to begin with?
You cannot talk to non SSL connections from an SSL page.
It's there to enable a connection from an https web app. Otherwise it would be blocked as mixed content (e.g. if you just used ws). Because everyone has access to the localhost key in the Dropbox app, Dropbox uses additional mutual authentication after establishing the wss (this is actually also because other websites may try to access the local daemon). The wss is only there to indicate to the browser that Dropbox really wants to establish a connection between their web app and the local daemon. It's a lot of hoops to jump through to make it work, but it's the best way of doing it.
> It's there to enable a connection from an https web app
Oh! Thanks. Forgot about that.
We'll be changing the mixed-content detection soon to treat localhost as a secure transport (because it is from the network perspective), which will address the mixed content issue.
Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?
Not likely, as I think it will be blocked in the same way that mixed content is blocked (whether CORS is allowed or not). I think the plan is just to cut off access to localhost entirely whether intentioned or not, because WSS already has an Origin header which functions similarly to CORS when the client is a browser.
what I meant was that I think allowing CORS or a similar mechanism is probably enough, and breaking apps like Dropbox is not a great idea, even if there is a non standard mechanism to override it.
Yes I agree, and WSS already has that mechanism in place. A similar point was also raised in the issues thread but has not been responded to.
As I explained elsewhere, the origin header in WS(S) allows a server to overtly protect itself from a client. Unlike CORS, it doesn't allow the browser to make security decisions regarding requests, and so would not address any of the attacks we're trying to prevent.
Potentially, yes, and it's one of the ways we're looking at addressing per-page opt-in.