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>
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 J
>
> ·        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/`.

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>, @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.)