W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: Upgrade mixed content URLs through HTTP header

From: John Wong <gokoproject@gmail.com>
Date: Fri, 6 Feb 2015 01:21:50 -0500
Message-ID: <CACCLA569mscVMrXzr=enTgGKAa7UDhqR=M02X6Ks6kchfeeHvw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Alex Russell <slightlyoff@google.com>, Joel Weinberger <jww@google.com>, Emily Stark <estark@google.com>, Jim Manico <jim.manico@owasp.org>, Ryan Sleevi <sleevi@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
My 3.1415 cents basically say CSP-based reporting is very helpful even with
the noise. I always think there should be one single reporting mechanism
for all the security headers, rather than asking developer to write code
and detect the UI/Browser warning and find their code is causing trouble.
And this needs to be outside of CSP, a superset reporting mechanism that
CSP can forward to. I tend to think of it like shipping logs to logstash.
This can be a whole different header...

Now is auto-upgrading sub-resources a good security measure. I agree with
some of the concerns raised in Devdatta's bugzilla report (
https://bugzilla.mozilla.org/show_bug.cgi?id=776278). I apologize if i am
really shifting the main attention, and please excuse my inability to keep
up with the latest development:

Assuming there are 50/50 split of the world's legacy content now or will be
served over http and https, or only http. The auto-upgrade will fail 50/50.

Assuming there are 50/50 split of the world's legacy content now served
over https with SHA1 or https with SHA2, the auto-upgrade will fail 50/50.

Regardless, we have to deal with legacy clients, insecure and broken
resources. But a page isn't make up of 1 third-party but dozens. As a
browser user, and a developer, will auto-upgrade harm performance and user
experience? Does auto-upgrade subresource offers better security than not
when mixed content will eventually kick in if content is only http (or
browser yells at SHA1-insecure cert, which I assume will then fail with
mixed-content???).

John

On Fri, Feb 6, 2015 at 12:57 AM, Mike West <mkwst@google.com> wrote:

> On Fri, Feb 6, 2015 at 6:39 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>
>> 2) how to upgrade it to https (possibly via a directive
>>
> or via JS). I was focusing on the latter when talking about
>> ServiceWorkers. I guess it doesn't help in cases where you don't
>> actually support HTTPS in some obscure origin and thus can't upgrade
>> automatically.
>>
>
> We currently do mixed content (and CSP) checks before sending the request
> to the Service Worker. I'm not sure it would be a good idea to restructure
> that to wait for the SW to potentially rewrite the request. Also, the
> timing seems problematic. You can't register a SW until you're on an HTTPS
> page, at which point it't too late to start upgrading its requests.
>
> I think a CSP-based solution has some advantages here, but I guess I
> wouldn't be opposed to explaining it in terms of service workers if there's
> a good way of doing so. +Alex, who probably has opinions about SW's
> applicability.
>
> -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.)
>
Received on Friday, 6 February 2015 06:22:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC