2015-4-May-safety-pins.jpg

If the whole web were encrypted by default, communications engineers argued, then malicious actors wouldn’t be able to guess which web sessions were relatively important by whether or not they were encrypted. The technology existed, the standards were in place and most of these engineers were supportive.

It was 1999. And the encrypted web never happened.

In a renewed plea to web developers in April, Mozilla — the makers of the Firefox web browser, which is struggling to regain market share against Google Chrome — put forth to its contributing developers a draft of a four-stage deprecation plan for the use of unencrypted Hypertext Transfer Protocol (HTTP) protocol on the web.

Blanket Privilege

The proposal’s stages could prove controversial, if implemented. They involve establishing a concept called privileged contexts, a term developers use to refer to the rights a component of a system to access resources, with respect to that component’s relationship with the rest of the system.

In programming, a component of a program or a whole program may require authentication — a way to securely and reliably identify itself — to access protected resources (such as documents or even printers). When it requires permission, it and the other components are said to operate in privileged contexts.

The W3C standards body, which maintains the basic protocols of the web (including non-encrypted HTTP and encrypted HTTPS), defines the phrase this way: “Certain web platform features that have a distinct impact on a user’s security or privacy should be available for use only in privileged contexts.”

Today, encryption works by way of some form of certification that establishes a sense of identity for users. A web server that encrypts its content sends your browser its certified public key, which your browser verifies before using. That key is then used to generate a temporary session key that encrypts the session between you and the server, until either the key expires or the session ends.

Mozilla’s proposal would promote privileged contexts for the entire web — zones within which all communications require encryption. In Phase 0, all participants would agree on how to define “privileged contexts.”

Then in the three phases that would follow, the new context would spread itself like a security blanket, in Phase 1 extending to all newly implemented features of web protocols. After Phase 2, a subset of existing web protocols would require privileged context access.

Then in Phase 3, the entire web would become a security zone.

In an amended version of his original proposal to Mozilla contributors, published Thursday on Mozilla’s organizational blog, Firefox security lead Richard Barnes duly noted some skeptics’ concerns from all the discussion over the last few weeks.

“Removing features from the non-secure web will likely cause some sites to break,” wrote Barnes. “So we will have to monitor the degree of breakage and balance it with the security benefit.”

The Degree of Breakage

The security benefit, if there is one, depends on whether you support the idea that Secure Sockets Layer (SSL) or even its successor Transport Layer Security (TLS) is fairly safe. Which means you probably slept through April 2014, when the “Heartbleed” bug hit the Internet.

Heartbleed was the code name that someone, perhaps in the interest of promoting a future novel or movie, gave to an exploit for a gaping, retrospectively obvious, security hole in the OpenSSL open source rendition of SSL security. The hole had gone unnoticed for so long, many believe, because so few resources were devoted to OpenSSL’s upkeep over the last quarter century.

Put another way, the keys to the Internet were essentially the property of one fellow.

TLS operates, for the most part under the same principles as SSL, with the added benefit of working correctly. However, as participants in Mozilla’s open discussion argue, since TLS is the hub of a commercial industry, forcing everyday users to adopt TLS would be contrary to web principles.

“No, TLS certificates are not really free,” wrote security engineer Sven Slootweg on his personal blog Friday.

“Introducing forced TLS would create an imbalance between those who have the money and means to purchase a certificate (or potentially many certificates), and those who don't, all the while promoting a cryptosystem as being 'secure' when there are known problems with it. This is directly counter to an open web.”

The Only Option?

In a response to SSL/TLS skeptics Friday, Mozilla’s Barnes argued that using the existing HTTPS may be the only option, if only because the very notion of considering an alternative assumes a certain risk.

“A big part of the motivation for having HTTPS be the default is that historically we have gotten decisions about what needs to be encrypted wrong over and over again,” he wrote. “Using HTTPS by default avoids having to take the risk of getting it wrong.”

Mozilla is no stranger to the HTTPS-by-default argument. In 2012, the browser maker famously switched its default setting for launching search engines such as Google, to encrypted HTTPS.

Many Firefox users received the move as a bug.

Creative Commons Creative Commons Attribution 2.0 Generic License Title image by Public Domain Photos.