HTTP/2.0 to enforce HTTPS encryption
Chair of the working group developing the HTTP/2 protocol has revealed that the new protocol will only work with HTTPS URIs as a response to pervasive monitoring by law enforcement and government agencies across the globe.
Announcing the development Mark Nottingham tweeted “HTTP/2.0 will only work for https:// URIs — part of @ietf response to pervasive monitoring.”
Nottingham detailed the reasons behind such a decision in a mailer titled “Moving forward on improving HTTP’s security.” Nottingham revealed that the working group had three relevant proposals considering the increasing need of encryption over the web.
First one was “Opportunistic encryption for http:// URIs without server authentication — a.k.a. “TLS Relaxed” as per draft-nottingham-http2-encryption”, second was “Opportunistic encryption for http:// URIs with server authentication — the same mechanism, but not “relaxed”, along with some form of downgrade protection”, and the final choice was “HTTP/2 to only be used with https:// URIs on the “open” Internet. http:// URIs would continue to use HTTP/1 (and of course it would still be possible for older HTTP/1 clients to still interoperate with https:// URIs).”
Nottingham noted that the third option was the most preferred one since it was more straightforward; provides stronger protection against active attacks; is supported by browser vendors; and can be put into practice without changes to the existing draft for HTTP/2.0.
The chair however notes that it will be necessary to “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.”
“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.”
However, there are those who have already questioned the effectiveness of the new protocol given the provision of allowing HTTP. Michael Sweet, Chair of IEEE’s printer working group and a senior printing engineer at Apple, wrote “… I honestly don’t see how this WG can actually enforce/mandate https:// and still allow http:// URIs.”