HTTP/2 is the second major version of the HTTP network protocol used to drive the World Wide Web. It is based on SPDY, an open protocol developed mainly at Google as an improvement of the 20 years old HTTP protocol.
HTTP/2 was developed by the Hypertext Transfer Protocol working group of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardised in RFC 2068 in 1997. The working group presented HTTP/2 for consideration as a proposed standard in December 2014, and it was approved for publishing as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 in May 2015.
HTTP/2 is totally different from the HTTP 1.1 protocol in that it removes the bottle necks that made the old version so terribly inefficient. The protocol is a binary protocol and does not require an (expensive) connection for each resource the client wishes to download from the server.
But there is much more: multiplexing – multiple streams transparently passing through the same connection, header compression – HTTP header and coockie data is compressed, server data push, resource dependencies management and prioritisation.
Sounds like a brave new high-speed world wide web coming right toward us… just that … it’s already here!
Google Chrome implements HTTP/2, Internet Explorer as well, Edge anyway and Mozilla Firefox is part of the show too. In terms of servers, we are quite advanced as well: Jetty, Apache, NGINX, and more. At the time being, activating server-side HTTP/2 support requires a pro-active configuration, but still it’s often just a command line switch away. Clients support HTTP/2 out of the box and without asking the user. Various sites, for instance google.com is already served using HTTP/2.
So what’s the problem? Security!
HTTP/2 is a brand new protocol, implemented in 2015, yet starting to appear all over the internet. It has been introduced quite silently, especially from a security point of view. The “common developer” is rarely aware of these totally new concepts and features like “Server push of binary content” should make ring some security geek’s “attention please” bells.
In terms of tools support, the situation is not optimistic, to say the least. While Wireshark and cURL for instance are supporting HTTP/2, these versions are often not available yet in common distributions. Manual download and even manual compilation is frequently required to make these functionalities available. Kali 2, in it’s current state, has no serious support for HTTP/2. Higher-level tools like Burp Suite and ZAP have no HTTP/2 support even seriously (officially) planned. Can we blame them for not having re-written an entire new protocol stack from scratch in 6 months? Hardly!
Querying the CVE database in regards to HTTP/2 also makes clear that there is some serious lack security testing and transparency. Having a few “little” vulnerabilities reported for a new highly complex protocol stack sounds alarming.
HTTP/2 urgently needs more attention! Attention and transparency.
The potential attack surface of this new protocol appears to be huge and the more the protocol is employed, the more attention it will get. We have to make sure that this attention is not coming from the “Bad Boys ™” first.
So, arm your Fuzzers!
(Next post: Compile cURL with HTTP/2 support in Kali 2).
More on HTTP/2 in a human-readable format: http://http2-explained.haxx.se/
HTTP/2 the implementation status: https://github.com/http2/http2-spec/wiki/Implementations.