Sending data in plain text just doesn’t cut it in an age of abundant hack attacks and mass metadata collection. Some of the biggest names on the Web—Facebook, Google, Twitter, etc.—have already embraced default encryption to safeguard your precious data, and the next-gen version of the crucial HTTP protocol will only work for URLs protected by HTTPS.
Mark Nottingham, chair of the HTTPbis working group developing the HTTP 2.0 protocol for the Internet Engineering Task Force, made the announcement early Wednesday in a Worldwide Web Consortium mailing list.
HTTP/2.0 will only work for https:// URIs—part of @ietf response to pervasive monitoring. http://t.co/yPXrMLO8DR
— Mark Nottingham (@mnot) November 13, 2013
“I believe the best way that we can meet the goal of increasing use of TLS [Transport Layer Security] on the Web is to encourage its use by only using HTTP/2.0 with https:// URIs,” Nottingham wrote.
Leaping through hoops for backward compatibility
Non-encrypted HTTP URLs would continue to use the current HTTP protocol, though Nottingham says the HTTP 2.0 protocol will still need to formally define how the protocol handles unencrypted URLs.
That’s because the “HTTP 2.0 requires HTTPS” line becomes a but blurry further down om Nottingham’s announcement.
“To be clear—we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption,” he wrote. “However, for the common case—browsing the open Web—you’ll need to use https:// URIs and if you want to use the newest version of HTTP.”
Michael Sweet, a senior printing engineer at Apple and chair of the IEEE’s printer working group, wondered if those exemptions could hamper the overall effectiveness of the proposal.
“… I honestly don’t see how this WG can actually enforce/mandate https:// and still allow http:// URIs,” Sweet wrote. “So long as unencrypted URIs are supported by HTTP/2.0, the best you can do is make security recommendations since TLS is not REQUIRED for the open web.”
While mandating HTTPS for HTTP 2.0 will surely spur more widespread use of encryption in an age of pervasive surveillance, it won’t magically make all Internet traffic inherently spy-proof, and it wouldn’t be a completely painless rollout. (Here’s hoping SSL certificate authorities are ready for a rush of new customers!)
Nor is the proposal proceeding unchallenged.
“I strongly believe that support for unencrypted HTTP/2.0 is still needed and useful, particularly when you are routing it over an already ‘secure’ channel to a resource-constrained device,” Sweet wrote as part of his response to Nottingham. “…I also believe that HTTP/1.x has been so successful because of its ease (and freedom) of implementation. But [in my opinion] restricting [HTTP 2.0’s] use to https:// will only limit its use/deployment to sites/providers that can afford to deploy it and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.”
Other HTTPbis members have expressed reservations about the “HTTPS Everywhere” declaration.
The IETF’s decision to (mostly) mandate HTTPS encryption isn’t the end-all and be-all of the discussion, however. There are other encryption proposals on the table, and Nottingham said that “As HTTP/2 is deployed, we will evaluate adoption of the protocol and might revisit this decision if we identify ways to further improve security.”
One more step on a long road to a faster, safer Web
The HTTPbis Working Group’s last call for HTTP 2.0 is slated to occur in April 2014, before submitting HTTP 2.0 to the Internet Engineering Standards Group in November 2014 for consideration as a formal standard.
The current HTTP 2.0 draft implementation was inspired by Spdy, an open protocol that’s compatible with standard HTTP and uses TLS encryption almost universally.
When it goes live, the IEFT hopes for HTTP 2.0 to include Spdy-esque features like header compression, connection multiplexing, and (it now seems) default encryption—all of which would make the World Wide Web faster and more secure.
Microsoft, meanwhile, released an HTTP 2.0-friendly “Katana” server implementation in April 2013 to help convince the IETF to include some of its proposed changes in the final HTTP 2.0 protocol.
For a long and insightful discussion on the pros and cons of mandating HTTPS for HTTP 2.0, check out this Reddit thread.