Re: Proposal: Marking HTTP As Non-Secure

Hello Chris et al:

I'm a web developer. I did some vendor security-related development
sometime ago inside Konqueror. Some first thoughts:

* In principle, the proposal makes sense to me. Who doesn't want a more
secure web? Kudos for making it possible with ambitious proposals like this.

* The biggest problem I see is that to get an accepted certificate
traditionally you needed to pay. This was a show-stopper for having TLS
certs in small websites. Mozilla, EFF, Cisco, Akamai are trying to fix that
[1] and that StartSSL gives free certificates though. Just stating the
obvious: you either get easy and free "secure" certificates, or this
proposal is going to make some webmasters angry.


Regards,
--
[1]
https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
--
Eduardo Robles Elvira     @edulix             skype: edulix2
http://agoravoting.org       @agoravoting     +34 634 571 634

On Sat, Dec 13, 2014 at 1:46 AM, Chris Palmer <palmer@google.com> wrote:
>
> Hi everyone,
>
> Apologies to those of you who are about to get this more than once, due to
> the cross-posting. I'd like to get feedback from a wide variety of people:
> UA developers, web developers, and users. The canonical location for this
> proposal is:
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> .
>
> Proposal
>
> We, the Chrome Security Team, propose that user agents (UAs) gradually
> change their UX to display non-secure origins as affirmatively non-secure.
> We intend to devise and begin deploying a transition plan for Chrome in
> 2015.
>
> The goal of this proposal is to more clearly display to users that HTTP
> provides no data security.
>
> Request
>
> We’d like to hear everyone’s thoughts on this proposal, and to discuss
> with the web community about how different transition plans might serve
> users.
>
> Background
>
> We all need data communication on the web to be secure (private,
> authenticated, untampered). When there is no data security, the UA should
> explicitly display that, so users can make informed decisions about how to
> interact with an origin.
>
> Roughly speaking, there are three basic transport layer security states
> for web origins:
>
>
>    -
>
>    Secure (valid HTTPS, other origins like (*, localhost, *));
>    -
>
>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>    with minor TLS errors); and
>    -
>
>    Non-secure (broken HTTPS, HTTP).
>
>
> For more precise definitions of secure and non-secure, see Requirements
> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
> Content <http://www.w3.org/TR/mixed-content/>.
>
> We know that active tampering and surveillance attacks, as well as passive
> surveillance attacks, are not theoretical but are in fact commonplace on
> the web.
>
> RFC 7258: Pervasive Monitoring Is an Attack
> <https://tools.ietf.org/html/rfc7258>
>
> NSA uses Google cookies to pinpoint targets for hacking
> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>
> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>
> How bad is it to replace adSense code id to ISP's adSense ID on free
> Internet?
> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>
> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>
> Erosion of the moral authority of transparent middleboxes
> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>
> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>
> We know that people do not generally perceive the absence of a warning
> sign. (See e.g. The Emperor's New Security Indicators
> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
> Yet the only situation in which web browsers are guaranteed not to warn
> users is precisely when there is no chance of security: when the origin is
> transported via HTTP. Here are screenshots of the status quo for non-secure
> domains in Chrome, Safari, Firefox, and Internet Explorer:
>
> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>
> [image: ie-non-secure.png]
>
> Particulars
>
> UA vendors who agree with this proposal should decide how best to phase in
> the UX changes given the needs of their users and their product design
> constraints. Generally, we suggest a phased approach to marking non-secure
> origins as non-secure. For example, a UA vendor might decide that in the
> medium term, they will represent non-secure origins in the same way that
> they represent Dubious origins. Then, in the long term, the vendor might
> decide to represent non-secure origins in the same way that they represent
> Bad origins.
>
> Ultimately, we can even imagine a long term in which secure origins are so
> widely deployed that we can leave them unmarked (as HTTP is today), and
> mark only the rare non-secure origins.
>
> There are several ways vendors might decide to transition from one phase
> to the next. For example, the transition plan could be time-based:
>
>
>    1.
>
>    T0 (now): Non-secure origins unmarked
>    2.
>
>    T1: Non-secure origins marked as Dubious
>    3.
>
>    T2: Non-secure origins marked as Non-secure
>    4.
>
>    T3: Secure origins unmarked
>
>
> Or, vendors might set thresholds based on telemetry that measures the
> ratios of user interaction with secure origins vs. non-secure. Consider
> this strawman proposal:
>
>
>    1.
>
>    Secure > 65%: Non-secure origins marked as Dubious
>    2.
>
>    Secure > 75%: Non-secure origins marked as Non-secure
>    3.
>
>    Secure > 85%: Secure origins unmarked
>
>
> The particular thresholds or transition dates are very much up for
> discussion. Additionally, how to define “ratios of user interaction” is
> also up for discussion; ideas include the ratio of secure to non-secure
> page loads, the ratio of secure to non-secure resource loads, or the ratio
> of total time spent interacting with secure vs. non-secure origins.
>
> We’d love to hear what UA vendors, web developers, and users think. Thanks
> for reading!
>