On Wednesday, June 21, 2017 at 11:51:27 AM UTC-5, Matthew Hardeman wrote: > On Wednesday, June 21, 2017 at 4:59:01 AM UTC-5, Ryan Sleevi wrote: > > > > > There are several distinct issues: > > 127.0.0.0/8 (and the associated IPv6 reservations ::1/128) > > "localhost" (as a single host) > > "localhost" (as a TLD) > > > > The issues with localhost are (briefly) caught in > > https://tools.ietf.org/html/draft-west-let-localhost-be-localhost - there > > is a degree of uncertainty with ensuring that such resolution does not go > > over the network. This problem also applies to these services using custom > > domains that resolve to 127.0.0.1 - the use of a publicly resolvable domain > > (which MAY include "localhost", surprisingly) - mean that a network > > attacker can use such a certificate to intercept and compromise users, even > > if it's not 'intended' to be. See > > https://w3c.github.io/webappsec-secure-contexts/#localhost > > > > 127.0.0.0/8 is a bit more special - that's captured in > > https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy > > I agree in full that there are several issues with localhost, the IP forms, > the loopback subnets, etc. > > Moreover, within my own mind, I simplify these to a single succinct desire: > > Break that entirely. There is never a time when I want a page served from an > external resource to successfully reference anything on my own device or any > directly connected subnet of a non-public nature. (For IPv6, maybe we call > that no external resource should successfully reference or access ANY of my > connected /64s). > > My comments above were merely to point out why people are acquiring these > certificates on public domains that resolve to 127.0.0.1. > > With the exception of the way Plex is/has been doing it (unique certificate > acquired via API from server-side for each system, assigning both a > certificate and a unique to the system loopback FQDN), these all involve > abuses where a private key for a publicly valid certificate is shared with > the end-user systems. > > If for no other reason than that normalizes and mainstreams an improper PKI > practice, those certificates should be revoked upon discovery. (It's called > a private key for a reason, etc, etc.) Obviously there are good causes > above and beyond that as well. > > I really am interested in seeing mechanisms to achieve this "necessary use > case" murdered. That the web browser with no prompt and no special > permission may interact in a non-obvious way with any other software or > equipment on my computer or network is far from ideal. > > The use case is also a nasty kludge. Why listed with a WebSocket on > loopback? Why not just build a client-side WebSocket connection from the > application back to the server side, where the server can then push any > administrative commands securely back to that application. I understand that > places more burden server-side, but it also provides a much better understood > (by the end users and their IT admins) flow of network communications. > > Frankly, if one is incorporating network stack code in their locally running > applications and yet want to use the browser as a UI for controlling that > application, there's a simple way of still having a browser UI and > controlling that application, even pulling in external resources to inform > the UI (if you must) -- embed the browser. Numerous quite embeddable engines > exist and are easily used this way. In those environments, the application > developer can write their own rules to avoid the security measures which get > in their way while still only creating a security train-wreck within the > context and runtime window of their own application. > > Perhaps I come across as somewhat vehement in my disdain for the purportedly > necessary use case that people are breaking this rule to achieve, but that's > been informed by my experiences over the years of watching people who have no > business doing so making security nightmares out of "clever" network hacks. > Among the favorites I've seen implemented was a functioning TCP/IP-over-DNS > which was built to provide actual (messy, fragmented, slow, but very > functional) full internet access to a site with a captive portal that would > still permit certain DNS queries to be answered. > > Short of intentional circumvention of network controls, the kinds of things > that are trying to be achieved by these local WebSocket hacks are indistinct > and, I believe, can not be technologically differentiated from the very > techniques one would use to have a browser act as a willing slave to a > network penetration effort. > > Here I favor public humiliation. Murder every mechanism for achieving the > direct goal of "serving the use case for a need for externally sourced > material loaded in the browser to communicate with a running local > application". Issue press releases naming and shaming every attempt along > the way. > > Goodness. I'll stop now before I become really vulgar.
I feel like this is getting sort of off-topic. Web pages can communicate directly with applications on the local machine regardless of whether they abuse certificates in this way or not. (Such as, for example, by using plain old HTTP.) The question of whether or not they should be able to do that is a separate topic IMO. Certificate abuse aside, I disagree with your assertion that this is inherently a bad thing. Even if browsers were to block web apps from communicating with localhost, they could still achieve pretty much the same thing by using an external server as a proxy between the web app and the locally installed application. The only major difference is that with that method they'd be using unnecessary internet bandwidth, introducing a few dozen extra milliseconds of latency, and would be unable to communicate offline - all downsides IMO. If you _really_ want to try blocking this anyway, you could always use a browser extension. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
