Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

On Fri, Jan 2, 2015 at 12:44 PM, Michal Zalewski <lcamtuf@coredump.cx>
wrote:

> > No script which works when served as http: should fail when instead
> served
> > from https:
>
> To make sure that we're all on the same page, it may be useful to draw
> a line between two fairly distinct scenarios:
>
> 1) An HTTP origin attempting to load a script that is served over
> HTTPS. As far as I can tell, in this case, the location from which the
> script is served is essentially immaterial - and the JS code will be
> not subject to any unusual constraints compared to any HTTP-delivered
> counterparts.
>
> 2) An HTTPS origin attempting to load a script that is served over
> HTTP. This is the scenario that the spec deals with and where browsers
> pull off all the mixed content blocking tricks.
>
> My initial reading of the proposed one-line addition to the spec
> (specifically, the "served" part) made me assume that the concern at
> the heart of this thread deals with the first use case. But in my
> understanding, this is not something that browsers try to restrict
> today, or that anyone aspires to (?).
>
> On the flip side, some of the later discussion - in particular, the
> two paragraphs starting with "This means that there is large class..."
> - suggest that the concern may be with the second use case, and that
> it would be preferable to go back to the old behavior where a HTTP
> script loaded on a HTTPS page simply resulted in a warning icon or a
> crossed-out "https://" string in the address bar.
>
> If it's the latter, I think that the breakage of some subset of web
> applications when migrated to HTTPS is a very valid worry that the
> authors of the spec are acutely aware of.
>
> Nevertheless, the big security concern with after-the-fact "tainted
> origin" indicators is that by the time they are shown, an
> unsafely-loaded and possibly attacker-modified script is already
> running in the security context of the parent HTTPS page. Because the
> creation of such scripts can happen at any point within an
> already-running application, and their presence can't be determined on
> the initial page load, it's very difficult to retroactively isolate
> the "tainted" execution context and prevent it from accessing any
> previously-entered secrets provided by the user with the assumption
> that they will be safe against network-level attacks.
>
It's also worth noting that this is something that some user agents already
do today (at least Chrome does; I am not sure of the state of things in
other browsers). While I agree with Tim that this is a concern, and we want
to make sure HTTPS adoption is as painless as possible for users and
developers, on a purely pragmatic level, in Chrome's experience, there have
been extremely few problems with mixed-script blocking. Thus, in some
sense, changing the wording would actually be a regression for some user
agents.

And on a personal level, I'm always surprised when I see the mixed
scripting shield *and the page still works perfectly* :-)

>
> Of course, there are many other ways to compromise the security of
> user data; but mixed content problems are extremely easy to introduce,
> and have been a notorious problem across the web despite browsers
> showing address bar warnings for more than a decade.
>
> If passive indicators are dangerous, there is always the option of
> giving users the choice to run unsafe scripts. That said, I'd posit
> that it's extremely difficult to explain the implications and have the
> users consistently make the right call.
>
> /mz
>
>