Header Ads

Chrome Mark HTTP web pages as insecure

The Chromium Project's security team has marked all HTTP web pages as insecure and is planning to explicitly and actively inform users that HTTP connections provide no data security protections.
There are also projects like Let's Encrypt, launched by the non-profit foundation EFF (Electronic Frontier Foundation) in collaboration with big and reputed companies including Mozilla, Cisco, and Akamai to offer free HTTPS/SSL certificates for those running servers on the Internet at the beginning of 2015.

Google is taking initiative to encourage website owners to switch to HTTPS by default. Few months ago, the web Internet giant also made changes in its search engine algorithm in an effort to give a slight ranking boost to the websites that use encrypted HTTPS connections.

Posted on their blog post

Marking HTTP As Non-Secure


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.


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.


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 and 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.


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! We are discussing the proposal on web standards mailing lists:

source: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

No comments

blogmytuts. Powered by Blogger.