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

On Tue, Mar 17, 2015 at 5:45 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

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

So far as I can tell, every browser reacts in some way to mixed content.
Safari is the most subtle, just dropping the lock from the address bar.
Chrome, Firefox, and IE have all more or less aligned to blocking stuff,
and have done so for quite some time.

I think (a) is a pretty small set.


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

IE blocks. IE has been blocking or modal-dialoging since ~4ish. Especially
in The Enterprise™, old IE isn't going anywhere anytime soon (Spartan is
looking significantly better, but their release cycle is, as yet, unclear).

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

Statcounter (
http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201402-201502-bar)
has some estimates. Eyeballing it, IE + old Firefox + Android is probably
+20%. Let's cut that in half and say 10%.

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.


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

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


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


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.

If you get to the HTTPS page, and you don't support upgrade, we won't
upgrade the subresource, you won't see the `upgraded` header, and you won't
set HSTS on the response.


> For http links in the
> presence of a network attacker, no upgrades will happen.
>

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


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

I don't understand the advantage you're claiming here. Yes, a MitM'd
initial connection breaks the scheme. That doesn't seem to be a unique
disadvantage of the proposal in the doc. Can you clarify?

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.


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

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

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

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)