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