Re: Proposal: Marking HTTP As Non-Secure

> Why not shift the onus from the user to the site operators? I would love
> to see a "wall of shame" for the Alexa top 1M sites that don't support
> HTTPS,
>

Just to follow up on this, from section 5.4 of
http://randomwalker.info/publications/cookie-surveillance-v2.pdf, 87% of
the sites from Alexa top 500 serve HTTP by default, and 66% of them don't
serve HTTPS at all, as measured by using HTTPS-Everywhere.

Thanks,
Monica


> redirect HTTPS to HTTP, and don't support HSTS. Perhaps search providers
> could use those to penalize rankings, as Google already does for non HTTPS
> sites. Efforts to make it cheap and easy to deploy HTTPS also need to
> advance.
>
> Thanks,
> Monica
>
> [1] http://lorrie.cranor.org/pubs/sslwarnings.pdf
>
> On Fri, Dec 12, 2014 at 4:46 PM, 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!
>> _______________________________________________
>> dev-security mailing list
>> dev-security@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security
>>
>