W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Sun, 14 Dec 2014 09:59:21 -0800
Message-ID: <CAOuvq22momj2ccBHrEJnSSVF7abg=oY41fdiP=VzYV3SyDZ8JA@mail.gmail.com>
To: Igor Bukanov <igor@mir2.org>
Cc: Eduardo Robles Elvira <edulix@agoravoting.com>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>, blink-dev <blink-dev@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>
On Sat, Dec 13, 2014 at 8:56 AM, Igor Bukanov <igor@mir2.org> wrote:

Free SSL certificates helps, but another problem is that activating SSL not
> only generates warnings, but just break the site due to links to insecure
> resources. Just consider a case of old pages with a few youtube videos
> served using http iframes. Accessing those pages over https stops the
> videos from working as browsers blocks access to active insecure context.
> And in case of youtube one can fix that, but for other resources it may not
> be possible.
>

Yes, unfortunately we have a collective action problem. (
http://en.wikipedia.org/wiki/Collective_action#Collective_action_problem)
But just because it's hard, doesn't mean we don't have try. I'd suggest
that embedders ask embeddees to at least make HTTPS available, even if not
the default.

Also, keep in mind that this proposal is only to mark HTTP as non-secure —
HTTP will still work, and you can still host your site over HTTP.


> So what is required is ability to refer to insecure context from HTTPS
> pages without harming user experience.
>

No, because that reduces or eliminates the security guarantee of HTTPS.


> For example, it should be a way to insert http iframe into https site.
> Similarly, it would be nice if a web-developer could refer to scripts,
> images etc. over http as long as the script/image tag is accompanied with a
> secure hash of known context.
>

Same thing here. The security guarantee of HTTPS is the combination of
server authentication, data integrity, and data confidentiality. It is not
a good user experience to take away confidentiality without telling users.
And, unfortunately, we cannot effectively communicate that nuance. We have
enough trouble effectively communicating the secure/non-secure distinction
as it is.
Received on Sunday, 14 December 2014 17:59:49 UTC

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