Re: [UPGRADE] Consider plan B for reduced complexity?

On Tue 2015-03-17 05:06:02 -0400, Mike West wrote:
> I think getting "most clients" on board "swift"ly is going to be difficult.
> I also think that legacy browsers are going to be around long enough to
> make it unlikely that folks can cleanly rely on new default behaviors
> without doing some work.

There are a few different classes of (versions of) User Agents that
we're thinking about here:

 a) User Agents that do not do any sort of mixed-content blocking at
    all.

 b) User Agents that do mixed-content blocking without
    upgrade-insecure-by-default.

 c) User Agents that do mixed-content blocking with
    upgrade-insecure-by-default.

At the moment, (c) is 0% ;)

We can further break down (b) into (b0) those UAs that have a rapid and
effective online upgrade path (e.g. Firefox and Chrome) and (b1) those
UAs that do not (Firefox ESR?  Some IE versions?  i don't actually know
what IE does with MIX...).

For planning such a transition, we don't care about the browsers in
group (a) at all.  Since they don't do MIX, they're going to be just as
broken in any case.

The holdouts that will hinder adoption are (b1).  Do we have an estimate
of how large a group this is?

> Making the behavior opt-in is a conservative, safe option that I believe I
> can sell to Blink's API owners. It leaves room for radical, risky
> experiments in parallel, but won't break any Forbsean sites that do strange
> things for strange reasons.

upgrade-by-default won't break Forbes.  What it might do is trigger the
load of a resource from https://forbes.com that otherwise wouldn't have
been loaded by browsers in group (b).  But UAs in group (a) already make
a request to http://forbes.com, which a network attacker can trivially
replay to https://forbes.com on behalf of the original UA.

There may be some weird corner cases that do get broken, but i've yet to
see a concrete example.  Compared to the gains from easing the path to
global HTTPS, these theoretical risks seem pretty small.

> It does less than you want, but significantly more than nothing, and seems
> like the right compromise approach to get things started. Getting something
> out into developers hands now seems like the best way to evaluate whether
> the impacts we're discussing here actually matter to developers interested
> in deploying the feature.

Right, but we also don't want to embed cruft in the stack permanently if
we can help it.

> The spec as-written handles the core use-case of upgrading HTTP to HTTPS by
> unconditionally sending a `Prefer` signal along with insecure navigational
> requests to which the server can respond with a redirect. It does not
> attempt to handle downgrading HTTPS to HTTP for upgrade-incapable clients,
> nor does it attempt to handle setting HSTS for upgrade-capable clients.
>
> On the issue of downgrades: I'm reluctant to add a header to every secure
> navigational request as well (as suggested in
> https://github.com/w3c/webappsec/pull/209), as I don't see how we'd ever be
> able to remove them once added. I agree that the downgrade procedure I
> proposed in https://github.com/w3c/webappsec/issues/212 is nuts. I don't
> have a good answer here other than UA sniffing (which, really, I don't
> think is that bad of an option).
>
> HSTS is something for which I think we can add a reasonable workaround: if
> we add an `upgraded: 1` (or similar) signal when we actually upgrade a
> resource (as proposed as part of https://github.com/w3c/webappsec/issues/212),
> then you can safely send `Strict-Transport-Security` along with the
> response to an upgraded request. That has the advantage of a) going away
> over time as folks edit their pages for legacy support, and b) applying
> only to sites that request upgrades. The more I think about it, the more I
> think we should add this: I've poked at it in
> https://github.com/w3c/webappsec/commit/05e5358eddcce3981a9f1afc5ff31bebc568cfb4.
> Alternate spelling suggestions welcome. :)

I don't think this works.  Many people will visit a site by following
links to it, and if a site supports https at all, many of those links
will be https:// links in the first place.  For http links in the
presence of a network attacker, no upgrades will happen.

If a user never does an explicit, non-interfered-with upgrade from
http:// to https:// then the server will never see Upgraded: 1, and thus
will never send the HSTS header.  This greatly reduces the utility of
HSTS from the scenario where a single https:// connection to the host
will repair future http:// connections.

We're already weakening HSTS considerably with these proposals, as we're
seeing it as a function of UA/origin interaction, rather than a property
of the origin itself.  (as a property of the origin itself, HSTS could
be aggregated and re-distributed by third-parties; we're at risk of
losing that if we expect conditional HSTS) Limiting HSTS to only being
sent on explicitly-upgraded connections will make it even weaker.

     --dkg

Received on Tuesday, 17 March 2015 16:46:08 UTC