Re: Restrict loopback address to Secure Contexts?

Hey Crispin, thanks for continuing the conversation!

On Tue, Sep 27, 2016 at 6:59 PM, Crispin Cowan <crispin@microsoft.com>
wrote:

> On Tue, Sep 27, 2016 at 9:43 AM, Crispin Cowan <crispin@microsoft.com>
> wrote:
>
> I agree that an origin is not to be trusted if it comes via HTTP.
>
>
>
> With that premise, I'd suggest that allowing HTTP arbitrary access to
> programs running on your local computer is a dangerous thing to do.
>
> *[Crispin] I did not say “arbitrary”, I specified post CORS preflight.
> Websites get to *request* access to loopback services, and those that wish
> to respond get to do so.*
>

Right now, it doesn't look like any browser is anywhere near making the
preflight proposal happen. Blink has a partial implementation, but a real
implementation that actually knows about socket connections before a
response comes in is difficult given our architecture. I'm on it, but it's
slow going (mostly because I have no idea what I'm doing, and happy
eyeballs is weird).

I'll feel better about this assertion about the power of access controls
when y'all are actually working on an implementation. As-is, it feels like
making theoretically perfect the enemy of the practically good. :)


> I made some arguments against this conclusion in my last email. What do
> you think about them?
>
> *[Crispin] Your argument that I could find is that opt-in is meaningless
> in the presence of a network attacker. This is not true, for 2 reasons:*
>
> *1.       *The loopback service can do its own end-to-end authentication.
> AuthN and crypto are always possible over cleartext channels.
>
Assuming that any local server went through the trouble of designing a
reasonable signing scheme (I have doubts), a network attacker who can
inject JavaScript into the non-secure origin can use whatever machinery is
tied to that origin in order to read and construct messages.

Also, WebAuthn and WebCrypto are both locked to secure contexts.

> *2.       *The loopback service may be insensitive to MitM attacks
> because the scenario just DOES NOT CARE about network attackers. If the
> data provided is public anyway, and not interesting to corrupt, then who
> cares if a MitM messes with it?
>
A few points:

1. I disagree with the notion of "public" you're suggesting here: a server
installed on my computer is not "public".

2. Everything is "interesting to corrupt", as it's software running locally
on my machine, probably with user-level (or root-level!) access. Tavis'
recent exploits don't make me terribly confident that the altimeter service
isn't also going to enable escalation.

> *[Crispin] I agree with blocking access to services that CANNOT defend
> themselves from HTTP sources. Location is an example, because it does not
> do any authenticating, has no authorization model, and leaks user personal
> information.*
>

1. Do you think there's a defense for confused local servers in the status
quo? Do you think one is likely to appear in the next X months?

2. Even in a world with preflights, the ACL is origin-based. If a network
attacker can control the origin to which a local server is communicating,
they can control the communication by impersonating the origin. It's not
clear what kind of defense you expect to be available and effective.


> *I do NOT agree with blocking fun new features from HTTP just to use as a
> cudgel to force web sites to migrate to HTTPS.*
>

Noted. I disagree with both the sentiment and the framing, but let's save
that for the next thread. :)

-mike