4 ms·

If it is local and communication never leaves the machine, why use TLS? 1Password got heat for the opposite in the past (use of ws:// between the browser exten

by ejcx 9y ago

If it is local and communication never leaves the machine, why use TLS? 1Password got heat for the opposite in the past (use of ws:// between the browser extension and the Mac Client). 1Password correctly pointed out that there isn't really a point to "secure communications" if the webserver and the web client are on the same machine. If you can't trust your own machine to intercept your connection then TLS is not going to save you. What I bet happened was some project manager said "There needs to be a green check" or some security person said "You NEED TLS" and nobody spoke up that it didn't make sense. edit: I'm not a deleter, but I misunderstood your post and I realized it right after I pressed enter. Did not realize you were talking about being on a remote webpage and being connected locally.

pilif 9y ago
Yeah. The webpage is remote and using ssl and now wants to talk to the locally installed app. I agree that SSL doesn’t make sense there and honestly, in my opinion it would make sense for browsers to treat localhost as a secure origin. But they don’t and so we’re back to square one which is that a secured origin can’t make requests to a non secured origin. Update: newer browsers do in-fact do this. It’s also part of the WHATWG spec: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501... Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement
- derefr 9y ago
  Interesting; intuitively, I would say that this should be fine for mobile browsers, but desktop browsers shouldn't be doing this—PC operating systems are still built on a fundamentally "mutually-untrustworthy multitenant time-sharing system" paradigm. Any random port on localhost (or, indeed, on any other IP assigned to the loopback interface—that's 127/8 in IPv4, you know!) can be a socket opened by a process running on your PC that was started by someone who 1. has limited shell access to your machine, but 2. who isn't you. Privileging such ports would give such attackers an easy escalation path from this limited shell access to administrative access, assuming that you yourself are a [local or domain] administrator. Mobile devices can ignore this because they're (so far) inherently single-user devices. But anything allowing multiple parallel user sessions—even a Chromebook, or an iPad in Classroom mode—shouldn't make the assumption that local ports are safe. That's how a teacher gets their password phished by their students.

by ejcx 9y ago

pilif 9y ago

Yeah. The webpage is remote and using ssl and now wants to talk to the locally installed app. I agree that SSL doesn’t make sense there and honestly, in my opinion it would make sense for browsers to treat localhost as a secure origin. But they don’t and so we’re back to square one which is that a secured origin can’t make requests to a non secured origin. Update: newer browsers do in-fact do this. It’s also part of the WHATWG spec: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501... Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement

derefr 9y ago
Interesting; intuitively, I would say that this should be fine for mobile browsers, but desktop browsers shouldn't be doing this—PC operating systems are still built on a fundamentally "mutually-untrustworthy multitenant time-sharing system" paradigm. Any random port on localhost (or, indeed, on any other IP assigned to the loopback interface—that's 127/8 in IPv4, you know!) can be a socket opened by a process running on your PC that was started by someone who 1. has limited shell access to your machine, but 2. who isn't you. Privileging such ports would give such attackers an easy escalation path from this limited shell access to administrative access, assuming that you yourself are a [local or domain] administrator. Mobile devices can ignore this because they're (so far) inherently single-user devices. But anything allowing multiple parallel user sessions—even a Chromebook, or an iPad in Classroom mode—shouldn't make the assumption that local ports are safe. That's how a teacher gets their password phished by their students.