Re: Upgrade mixed content URLs through HTTP header

Could we use CSP for this?

default-src https: 'upgrade-unsafe'
On Feb 3, 2015 10:03 AM, "Mike West" <mkwst@google.com> wrote:

> On Tue, Feb 3, 2015 at 8:40 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> 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.
>
>
> This actually seems meaningfully different from the way we've phrased the
> question before. If we began interpreting strict transport security as
> rewriting all URLs on a page, we'd avoid some of the questions around
> request-order-specific behavior.
>
> In MIX, we currently point to some of this in
> https://w3c.github.io/webappsec/specs/mixedcontent/#further-action. I'd
> been thinking about STS as a signal to enable strict-mode (e.g. don't even
> attempt to load any insecure resource), but optimistically rewriting
> resource URLs (and hard-failing if they fail to load) is an interesting
> approach.
>
> On Tue, Feb 3, 2015 at 1:42 AM, Peter Eckersley <pde@eff.org> wrote:
>
>> > That said, I'm not sure it actually solves W3C's concern, as it would
>> leave
>> > legacy clients out in the cold. The only way to support clients that
>> don't
>> > support the thing we haven't implemented yet would be to alter the
>> links at
>> > the source. I totally understand that that's difficult, but it seems
>> > essential.
>>
>> It seems like you're saying that a security mechanism can't be allowed
>> to help new clients upgrade to HTTPS if it doesn't also help old ones?
>>
>
> That's not what I mean to say. With regard to the W3C, my (apocryphal?*)
> understanding is that the main blocker to deploying HTTPS more widely is
> legacy clients, not legacy content, and that they'd need to alter the
> source in order to get over that hurdle. The legacy concern was specific to
> this example, not a general statement on adding features to the platform.
>
> *Wendy (hi!) could probably comment here.
>
> --
> 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.)
>