Re: Upgrade mixed content URLs through HTTP header

On Tue 2015-02-03 21:11:51 -0500, Tom Ritter wrote:
> I also don't like coupling: we definitely can't make HSTS
> automatically imply some new behavior and break existing sites. [0] If
> anything, a new directive should be used.

I understand the general hesitation about coupling -- you don't want to
pull the rug out from under people who have already deployed something.

However, i am not convinced that the following subtle change in
semantics would be a problem for *anyone*; it could help some existing
STS deployments; and it could encourage more sites to adopt STS.  I'm
proposing:

 * When a user agent has a site marked for STS,

 * And any page is loaded from that site that has an http subresource
   that is blocked because of mixed content blocking,

 * Then, rather than blocking the subresource, transform the http URL to
   https and try to fetch it.

If the subresource is not avaiable because an https connection cannot be
made, the user experience is no worse than the earlier mixed-content
blocking scenario.

If the subresource is available via https, it is a strict improvement
over the blocked mixed content.



This doesn't solve all possible problems: in particular, it doesn't
address the question of what to do with unblocked mixed content that
might trigger the degraded security indicator.  A separate directive
with the semantics of "prefer http→https upgrades for unblocked mixed
content instead of fetching in the clear with a degraded security
indicator" would address this.

However, I see no reason that we should avoid coupling opportunistic
upgrade for blocked mixed content for sites already using STS.  Is there
a coupling objection to this use case that i'm missing?

        --dkg

Received on Wednesday, 4 February 2015 04:47:13 UTC