RE: Restrict loopback address to Secure Contexts?

On the perfect being the enemy of the good: you are quite right, I am describing an idealized world. I thought that’s what Standards are for, and we then work towards them? Conversely, it seems like it would be bad to standardize on “good enough for now” and then need to change it.

Edge can’t do an effective job of CORS Preflight right now due to architectural issues which we hope to address in the future. Meanwhile we keep Edge users safe from loopback attack with a different mitigation that is not worthy of floating as a standard.

What is “happy eyeballs”? ☺

Local server doing authN: when we pass the Origin to the loopback service, do we pass the whole Origin? I.e. do we tell them whether it is HTTP or HTTPS? If so, then the service can make up its own mind whether an inauthentic origin is ok.

I agree that a service doing hand-rolled crypto *correctly* is unlikely. The more likely scenario is a loopback service that doesn’t care about privacy or integrity, it just wants to advertise some data to any web site that asks.

Also, to be clear, I have no complaint at all if Chrome chooses to block loopback access from HTTP sites. Edge also blocks loopback access in non-standard ways to assure a degree of user safety, it is just different from what you propose because we are dealing with different architectural issues.

From: Mike West [mailto:mkwst@google.com]
Sent: Tuesday, September 27, 2016 10:57 AM
To: Crispin Cowan <crispin@microsoft.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>; wilander@apple.com; public-webappsec@w3.org
Subject: 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<mailto:crispin@microsoft.com>> wrote:
On Tue, Sep 27, 2016 at 9:43 AM, Crispin Cowan <crispin@microsoft.com<mailto: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