- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 03 Feb 2015 22:21:01 +0100
- To: public-webappsec@w3.org
Hi, Probably saying something super-naive, but trying anyway. What about having the described behavior without a new opt-in? The use case being discussed is moving large bodies of content to HTTPS. In the HTTP version of the site, the cross-domain <img> and <script> work. If moving naively to HTTPS, these break because of mixed-content blocking. If the HTTPS version of these resources is attempted to be fetched we have one of the two outcomes: 1) the resource exists with HTTPS as protocol : Cool, it's all we wanted 2) the resource doesn't exist with HTTPS as protocol : well, whatever, the page was going to be broken anyway because of mixed content blocking. So, good case: better security, all works fine, worst case is as bad as the current state of affairs. David Le 02/02/2015 16:24, Anne van Kesteren a écrit : > Some members of the W3C staff raised this issue the most clearly, > though I also found out myself while rolling out TLS on whatwg.org and > various other domains. > > When you have lots of legacy pages that all have various subresources, > upgrading them all to avoid mixed content warnings (or worse, > failures) can be a pain. You have enabled TLS for the domains your > subresources come from, but you don't have the possibility of > upgrading all the links. > > For that scenario it would be useful if we had a header that was > similar to HSTS, but instead applied to the subresources of the > current document. HSTS does not help as it a) applies only to a single > host and any cached hosts and b) happens after mixed content per > recent agreement. > > So I think if we introduced an HTTP response header (only takes affect > if delivered over TLS) like > > TLS-Only: true > > we would enable resources such as > > <!doctype html> > <title>Hey!</title> > <h1><img src=http://elsewhere.example/test alt=Testing></h1> > <script src=http://anywhere.example/run></script> > > to avoid mixed content warnings without content changes. > > This seems fairly trivial to introduce and support and would lower the > barrier to TLS adoption some more. Especially for web properties with > lots of legacy resources. > >
Received on Tuesday, 3 February 2015 21:21:31 UTC