LOS ANGELES — In its latest move to boost the security of the web and to encourage site owners to take a more proactive approach to securing their sites, Google’s popular Chrome browser will soon begin to flag sites using the HTTP protocol as being unsafe.
While it is common knowledge that sites using the HTTP protocol are vulnerable to attack and to all sorts of security problems — and the alternative HTTPS protocol that employs Secure Socket Layer (SSL) encryption to secure communications between web clients and servers has long been readily available — most websites have simply not bothered to upgrade their infrastructure.
SSL relies in part on the registration of a digital certificate that identifies the true ownership of a website and then uses this information to encrypt the user’s browsing session for greater security. Most browser software will display a padlock icon or turn the navigation bar green in order to distinguish a secure site from an insecure one. Google will take this a step further by popping a warning on standard HTTP pages.
The move is the result of a proposal from the Chrome Security Team to have user agents (UAs) such as web browsers to “gradually change their UX to display non-secure origins as affirmatively non-secure,” with a goal of “more clearly [displaying] to users that HTTP provides no data security.”
For its part, Google will transition Chrome to trigger these non-secure site warnings in 2015. The popular search engine is already giving a slight boost to secure HTTPS sites in its rankings, with the weight of this factor expected to grow significantly as its security initiatives roll out.
While currently a gradual and incremental shift towards securing the web through rewarding proactive sites for their customer care, the punitive end of Google’s “carrot and stick” approach will surface when the visitor to a non-secure site is displayed a warning that it is a questionable resource that they visit at their own peril. Although the company is attempting to ease the countless HTTP sites into compliance, its intention to ratchet up the heat is clear.
“We all need data communication on the web to be secure (private, authenticated, untampered),” the team noted in a recent blog post. “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.”
The team explains that there are three basic transport layer security states applicable to websites, which include “Secure” (sites using valid HTTPS), “Dubious” (sites with valid HTTPS but mixed passive resources or with minor TLS errors), and “Non-secure” (covering sites with broken HTTPS or old style, basic HTTP).
Complicating the matter for many adult website operators is the fact that all elements of a page must be served via HTTPS for an otherwise valid HTTPS page to be considered secure. This means that although a site has a valid security certificate and follows the SSL protocol, third-party content that is not securely delivered will “break the lock” and trigger the insecure site warning.
For example, the common use of iframed ads and content, such as live cam widgets and other add-ons, served via HTTP, will render a secure site insecure. This problem will persist until all affiliate programs, ad networks and service providers such as content plugins, statistics tools and traffic exchanges make their tools secure and available via HTTPS.
The writing is now clearly on the wall, with website operators receiving ample warning to up their game — or be lumped in together with the web’s scammers and non-professional (read “untrustworthy”) websites.