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

Re: Proposal: Marking HTTP As Non-Secure

From: Igor Bukanov <igor@mir2.org>
Date: Mon, 15 Dec 2014 11:03:14 +0100
Message-ID: <CADd11yVTb-vGMMRVNA--3oHLZHg=tV+nOMLKfkSuBTC4005tqw@mail.gmail.com>
To: Michal Zalewski <lcamtuf@google.com>
Cc: Peter Bowen <pzbowen@gmail.com>, Chris Palmer <palmer@google.com>, 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 15 December 2014 at 10:30, Michal Zalewski <lcamtuf@google.com> wrote:

> That seems somewhat tangential to Chris' original proposal, and there
> is probably a healthy debate to be had about this; it may be also
> worthwhile to look at SPDY and QUIC. In general, if you're comfortable
> with not providing users with a visible / verifiable degree of
> transport security, I'm not sure how the proposal changes this?

Chris' original proposal is a stick. I want to give a site operator also a
carrot. That can be an option to activate encryption that is not visible to
the user and *receive* from the browser all reports about violations of
secure origin policy. This way the operator will know that they can
activate HTTPS without worsening user experience and have information that
helps to fix the content.

If there is genuinely no distinction between plain old
> HTTP and opportunistically encrypted HTTP, the scheme can be
> immediately rendered useless by any active attacker

I am not proposing that a user-invisible encryption should stay forever.
Rather it should be treated just as a tool to help site operators to
transition to the proper https so at no stage the user experience would be
worse than continuing to serve pages with plain http.
Received on Monday, 15 December 2014 10:03:42 UTC

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