RE: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

Thanks for the detailed feedback.

So, one part of my post was correct: the newbie alert ☺ Thanks folks.

From: Mike West [mailto:mkwst@google.com]
Sent: Wednesday, February 11, 2015 1:53 AM
To: Crispin Cowan
Cc: public-webappsec@w3.org; Brad Hill; Dan Veditz; Wendy Seltzer; Peter Eckersley; yan zhu
Subject: Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

On Tue, Feb 10, 2015 at 7:10 PM, Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>> wrote:
I made a suggestion a while back that got one positive response, but then seemingly ignored.

Hi Crispin! Sorry I ignored you, that certainly wasn't my intent!

That there should be a “strict” mode e.g. for banks that want absolutely all traffic encrypted, and a “slack” mode e.g. for mashup web sites that want to encrypt all of their own content, but not that coming from some other web sites that they are pulling from.

The doc proposes 3 modes:

•        “Enforced upgrade”: this is pretty much exactly what I meant by “strict”

•        “Monitored upgrade”: I didn’t address this ☺

•        No upgrade: seemingly implicit in the absence of directives.

I suggest adding a 4th mode:

•        “Local upgrade”: upgrade all content coming from this origin/server, and don’t attempt to upgrade stuff coming from other servers
I felt like your suggestion wrapped up into the similar suggestion that we move to a more granular `*-src` mechanism. I added that to the document as issue #1 (https://w3c.github.io/webappsec/specs/upgrade/published/2015-02-FPWD.html#issue-de701aab).

Assuming an `upgrade-src` directive (or something more clearly named), my proposal maps to `upgrade-src *`, and your "local upgrade" proposal maps to `upgrade-src 'self'`. If we have those to, I don't see why we wouldn't also want `upgrade-src 'self' http://my-totally-awesome-cdn.com/`<http://my-totally-awesome-cdn.com/%60>.

My concern is that that would be overly complex, both for authors and user agents to implement, and for authors to maintain on their sites.

Local is basically saying “upgrade stuff that can be upgraded, but explicitly tolerate mixed content.” Clearly that is less secure. But it is more secure than no upgrade, which is where people using mixed-source content will be forced to go.

I think we need to get some feedback from developers to understand where the pain points actually lie.

My suspicion is that most developers care about two things:

1. Scripts, XHR, etc. "stop working" when they migrate to HTTPS.
2. The address bar breaks in some way (yellow triangle, shield icon, etc) and scares their users.

It's not clear to me that there's much value in providing a solution that doesn't consistently solve those problems (and, as Jim notes, still leaves you vulnerable to the Bad Things that mixed content doesn't yet mitigate). But I may be misinterpreting the feedback from EFF and W3C folks. Maybe something more granular really would be helpful. If it is, we should absolutely put it into the document.

-mike

--
Mike West <mkwst@google.com<mailto:mkwst@google.com>>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)