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 10:17:07 -0800
Message-ID: <CAOuvq20h+4O++vr2zP5O1kTki_QK1d6c-67=gEo6VwDT8m4=VQ@mail.gmail.com>
To: Christian Heutger <christian@heutger.net>
Cc: "edulix@agoravoting.com" <edulix@agoravoting.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "blink-dev@chromium.org" <blink-dev@chromium.org>, "security-dev@chromium.org" <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On Sat, Dec 13, 2014 at 11:05 AM, Christian Heutger <christian@heutger.net>

 I see a big danger in the current trend. Expecting everyone having a free
> „secure“ certificate and being in requirement to enable HTTPS it will
> result in nothing won. DV certificates (similar to DANE) do finally say
> absolute nothing about the website operator.

Reducing the number of parties you have to trust from [ the site operator,
the operators of all networks between you and the site operator ] to just [
the site operator ] is a huge win.

> They ensure encryption, so I can then be phished, be scammed, … encrypted.
> Big advantage!^^ Pushing real validation (e.g. EV with green adressbar and
> validated details by an independent third party, no breakable, spoofable
> automatism) vs. no validation is much more important and should be focussed
> on.

I think you'll find EV is not as "extended" as you might be hoping.

But more importantly, the only way to get minimal server auth, data
integrity, and data confidentiality on a mass scale is with something at
least as easy to deploy as DV. Indeed, you'll see many of the other
messages in this thread are from people concerned that DV isn't easy enough
yet! So requiring EV is a non-starter.

Additionally, the web origin concept is (scheme, host, port). Crucially,
EV-issued names are not distinct origins from DV-issued names, and
proposals to enforce such a distinction in browsers have not gotten any
traction because they are not super feasible (for a variety of reasons).

> However, this „change“ could come with marking HTTP as Non-Secure, but
> just stating HTTPS as secure is the completely wrong sign and will result
> in more confusion and loosing any trust in any kind of browser padlocks
> than before.

HTTPS is the bare minimum requirement for secure web application
*transport*. Is secure transport by itself sufficient to achieve total
*application-semantic* security? No. But a browser couldn't determine that
level of security anyway. Our goal is for the browser to tell as much of
the truth as it can programatically determine at run-time.

Received on Sunday, 14 December 2014 18:17:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC