Re: Upgrade mixed content URLs through HTTP header

I see, yes using CSP for reporting only is a good idea. And HSTS makes
sense too.

Would this enable the upgrade only? Without the STSing?

Strict-Transport-Security: max-age=0; upgradeSubresources
 On Feb 3, 2015 10:16 AM, "Mike West" <mkwst@google.com> wrote:

> If we needed a separate header, sure, CSP is a nice delivery mechanism. I
> like hanging it on STS, as that's a pretty strong signal that you're trying
> to do the right thing with regard to security.
>
> I'd also like to be able to use CSP as a mechanism for authors who care to
> learn about pages on their sites that are being auto-upgraded so they can
> be fixed. (e.g. `Content-Security-Policy-Report-Only: default-src https:;
> report-uri /insecure-resources-go-here/`).
>
> -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.)
>
> On Tue, Feb 3, 2015 at 10:09 AM, Eduardo' Vela" <Nava> <evn@google.com>
> wrote:
>
>> 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.)
>>>
>>
>