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

> 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.

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

Received on Friday, 2 January 2015 20:45:09 UTC