3 ms·

The reason that web apps such as Dropbox currently go to all the effort of a public DNS record (www.dropboxlocalhost.com) resolving to 127.0.0.1 plus an SSL cer

The reason that web apps such as Dropbox currently go to all the effort of a public DNS record (www.dropboxlocalhost.com) resolving to 127.0.0.1 plus an SSL certificate for that domain, plus mutual authentication after the websocket is established, is because it's currently the only pragmatic way to setup a non-"mixed content" connection to a localhost websocket server. It doesn't increase security as you point out. It's just that it's the only way to do it. Any other connection would be blocked by browsers (e.g. a connection from https web app to a non-tls ws localhost server). The bug ticket referred to would seek to block this last remaining way of connecting, forcing localhost daemons to connect to the web app via server proxy.

xg15 12y ago
Okay, that makes sense. But then the real problem is that solving what should be a trivial technical problem today requires an extremely wasteful workaround. If I understood jschuh correctly in [1] and [2], then they plan to make this workaround unnecessary by treating connections to localhost as secure even when over plain http/ws. As I understood, connecting to a daemon, both over ws and wss will still be possible, as long as the - to be defined - opt-in headers are sent by the daemon. In fact, the associated change to mixed-content would even allow using plain ws://localhost on secure sites, which - as you told - isn't possible today. Apparently vulnerable services exist and this is a security hole that needs to be closed. So legitimate users of local connections need to update their implementations anyway. If that's the case, I'd prefer a solution which just requires me to add a new response header and not need me to manage a new DNS entry and TLS cert for no real benefit. I agree though that this change has possible sweeping implications and should be done as part of the usual HTML5 process and not unilaterally be chrome. Also, the opt-in protocol must be specified before this change comes into effect. [1] https://news.ycombinator.com/item?id=9211034 https://news.ycombinator.com/item?id=9211034 [2] https://news.ycombinator.com/item?id=9210985 https://news.ycombinator.com/item?id=9210985

xg15 12y ago

Okay, that makes sense. But then the real problem is that solving what should be a trivial technical problem today requires an extremely wasteful workaround. If I understood jschuh correctly in [1] and [2], then they plan to make this workaround unnecessary by treating connections to localhost as secure even when over plain http/ws. As I understood, connecting to a daemon, both over ws and wss will still be possible, as long as the - to be defined - opt-in headers are sent by the daemon. In fact, the associated change to mixed-content would even allow using plain ws://localhost on secure sites, which - as you told - isn't possible today. Apparently vulnerable services exist and this is a security hole that needs to be closed. So legitimate users of local connections need to update their implementations anyway. If that's the case, I'd prefer a solution which just requires me to add a new response header and not need me to manage a new DNS entry and TLS cert for no real benefit. I agree though that this change has possible sweeping implications and should be done as part of the usual HTML5 process and not unilaterally be chrome. Also, the opt-in protocol must be specified before this change comes into effect. [1] https://news.ycombinator.com/item?id=9211034 https://news.ycombinator.com/item?id=9211034 [2] https://news.ycombinator.com/item?id=9210985 https://news.ycombinator.com/item?id=9210985