Re: Upgrade mixed content URLs through HTTP header

On Mon, Feb 2, 2015 at 7:53 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> Why does this need to be a separate header at all?  Why not just assume
> that sites with STS set should opportunistically upgrade http resources
> to https?

We have already decided that a resource on example.com (with HSTS)
that has a subresource <img src=http://example.com/img> will result in
a mixed content warning.

It seems unlikely that will revert that and furthermore also couple
HSTS with upgrading all subresources, regardless of host. Therefore a
new header is suggested.


> I understand that there are some small minority of sites like
> https://forbes.com/ that are radically different from
> http://forbes.com/

I don't see how this would be applicable in an HSTS scenario.


> Given that the operators of the origin server who send STS are going to
> ensure that they don't do this Bad Idea, and that they don't actually
> have any control over external sites that might do this Bad Idea, having
> a separate header to proclaim "we think everyone we pull resources from
> is serving the same content on https" doesn't seem like much of a win.

It might actually be the fact that they control all the resources,
including all subresources on various hosts, but they don't want to go
through the effort of rewriting the content.


> (if i'm pulling an image or a script from http://forbes.com/ in my site
> that's covered by STS, it'll fail to load the image either way)

That is untrue for the image. Anyway, the scenario here is not you
pulling content from random hosts. The scenario is having a large set
of host names that you pull subresources from, knowing they all
support TLS, and having a large body of content you would like to
avoid rewriting.


-- 
https://annevankesteren.nl/

Received on Tuesday, 3 February 2015 07:40:35 UTC