W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

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

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Tue, 17 Mar 2015 20:50:32 -0400
To: Mike West <mkwst@google.com>
Cc: Peter Eckersley <pde@eff.org>, David Walp <David.Walp@microsoft.com>, Tanvi Vyas <tanvi@mozilla.com>, Crispin Cowan <crispin@microsoft.com>, Dan Veditz <dveditz@mozilla.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
Message-ID: <87fv93m8mf.fsf@alice.fifthhorseman.net>
On Tue 2015-03-17 14:59:51 -0400, Mike West wrote:
> On Tue, Mar 17, 2015 at 5:45 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 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.
>>
>
> Consider `translate.google.com`, which frames third-party sites (proxying
> the initial, translated HTML page, but passing through subresource
> requests). If we upgrade-by-default, this will likely break, as those sites
> won't serve resources over HTTPS.
>
> Consider `https://overcast.fm/podcasts/episode/51912860522`, which loads
> podcasts over HTTP (and simply accepts the mixed content warning, which is
> weird :) ). If we upgrade-by-default, this will likely break, as those
> podcasts aren't available over HTTPS.
>
> I suspect that if we actually start looking (and changing browser behavior
> for X% of users), we'll find more.

You seem to be assuming that i'm advocating for upgrading
optionally-blockable content by default.  I'm not.

I'm advocating upgrading blockable content by default, and leaving
optionally-blockable content to be dealt with separately.

> Glad we agree on that. I believe the proposal I've made minimizes
> cruft by limiting the signals to specific scenarios that we want to
> drive down. The claim here, I suppose, is that the
> `upgrade-insecure-requests` signal is itself cruft? My suspicion is
> that we won't be able to get rid of optionally blockable mixed content
> via automagical upgrade; opting-in via the directive seems like the
> right way to approach it, which means that the directive will still
> have use for years to come (unfortunately).

Maybe you're saying we need two signals, one for optionally-blockable
and one for blockable content?

> If you get to the HTTPS page and you support upgrade, then we'll upgrade
> subresource requests locally before hitting the network, adding the
> `upgraded` header, and delivering it. There shouldn't be plaintext in that
> scenario, so you'll see the header and add HSTS to the response.

But the subresources might only be to other origin servers, not to the
same-origin (e.g. because the admin was good and fixed all your own
internal links).  In this case, the only HSTS header you'll see will be
from the other traffic.

> Correct. I don't think any proposal on the table blocks an active network
> attacker from MitMing the initially insecure connection.

sure, but some proposals block active network attackers from MitMing
*any* insecure connection after a single secure connection has gone
through.  The proposal to only send HSTS conditionally fails that test.

> If HSTS can only be set for certain user agents, it is by definition a
> UA/origin interaction.

Right.  the HSTS2 proposal can be set unilaterally (only browsers that
do automatic upgrades of blockable content will respect it), and is
therefore not a UA/origin interaction.

> You're saying that we're weakening HSTS; I don't see how, given that
> status quo is zero HSTS for the authors we're targeting with this
> proposal, and the proposal would enable more-than-zero HSTS.

As originally proposed, HSTS is UA-independent.  It's simple to deploy,
and easy to aggregate and share sensibly.  HSTS2 would also be
UA-independent.

The proposal under discussion ends up encouraging setting HSTS on a
per-user-agent basis, which breaks both of these properties.

> You're correct to say that the proposal in the doc does not completely
> solve the problem. I'm explicitly aiming for a minimal first pass that
> we can launch and iterate upon.

I appreciate that, and share these goals! i'd also like to see something
that we can roll out; hopefully we can hit on a way that will solve most
issues while leaving deployment relatively easy and avoiding permanent
protocol cruft.

Regards,

           --dkg
Received on Wednesday, 18 March 2015 00:51:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC