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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
