Re: Upgrade mixed content URLs through HTTP header

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.)
>>
>