Minerva Studio - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Will HTTP/2 satisfy the need for speed and enterprise Web security?

HTTP/2 is close to becoming a formal Internet specification -- but how will it affect enterprise Web security? Expert Michael Cobb discusses how features, including compression and encryption, may help boost HTTP's safety.

The first revision of HTTP in 16 years is close to becoming a formal Internet specification; HTTP/2 has been approved by the Internet Engineering Steering Group (IESG), and is in the RFC Editor's publication queue.

But what will this change ultimately mean for enterprise Web security?

In this tip, I will take a look at some of the current issues with the HTTP protocol and how improvements in HTTP 2.0 will potentially remedy them, namely with features like compression and encryption.

The problem with HTTP

The Hypertext Transfer Protocol (HTTP) is the underlying request-response protocol used by the World Wide Web. Despite the rapid evolution of the Internet, the version of HTTP most commonly used today -- HTTP/1.1 -- was last updated in 1999.

The demand for ever-quicker content delivery times in today's world means HTTP/1.1 is no longer fast or efficient enough.

HTTP/1.1 differed from its predecessor -- HTTP/1.0 -- by being able to reuse a connection multiple times to download page content, which makes load times a lot quicker as it removes the need to establish a new connection for each page resource. The demand for quicker content delivery times in today's connected, bandwidth-intensive, mobile world, though, means HTTP/1.1 is no longer fast or efficient enough.

Enter HTTP/2

HTTP/2 is primarily focused on improving the time it takes to render a webpage. It's based largely on the SPDY protocol developed by Google, which can reduce the time it takes to deliver a webpage by more than 50%. High-volume sites such as Google, Facebook and Twitter already use the SPDY protocol. Google's ads are also served from SPDY-enabled servers, but it's currently used by less than 4% of all websites, according to W3Techs' research.

HTTP/2 is not a ground-up rewrite of the protocol, but unlike HTTP/1.1, which is a textual protocol, HTTP/2 is binary; binary protocols are more efficient to parse, more compact, and are much less error-prone. It supports the same high-level semantics as HTTP/1.1, such as methods, status codes, header fields and URIs. The difference is in how the data is framed and transported between the client and the server; HTTP/2 allows the server to send all the different elements that it knows a Web browser will need to render a webpage without waiting for it to examine the first response, which eliminates the serial sets of messages that still have to be sent back and forth with HTTP/1.1. HTTP/2 also provides an effective compression algorithm (HPACK) that is tailored to HTTP and avoids many of the security issues with using general purpose compression algorithms over TLS connections.

HTTP/2 is defined for both HTTP and HTTPS, but HTTPS requires TLS 1.2 or later with some additional requirements that are specific to HTTP/2, including a cipher suite blacklist and support for the Server Name Indication extension, a protocol that allows a client to indicate which hostname it is attempting to connect to at the start of the handshaking process.

The enterprise effect of HTTP/2

The working group did not have consensus to require the use of TLS in HTTP/2, and although major browsers vendors already support HTTP/2 by default, they will only support it when it is used over an encrypted connection. So, if enterprise website administrators want to benefit from HTTP/2 and speed up the load time of their site, they will have to buy and deploy a Web server certificate.

There are implementation risks with any new protocol.

The code of enterprise Web applications won't need updating to benefit from the new protocol, only client and server software. However, servers will be fielding many more requests at once as clients can send requests much more quickly. Caching and load-balancing services may need upgrading due to the need to commit more resources to each connection.

Some concerns have arisen about a possible DDoS attack vector if attackers find ways to abuse the new method for handling header content if browser and software vendors fail to interpret and implement the protocol correctly. However, there are implementation risks with any new protocol.

Enterprises should note that Web security gateways may also need their rules and filters updated to handle the larger amount of data that will be within the headers received when users on the internal network request content from a website.

HTTP/2 is currently available in Firefox and Chrome for testing, using the h2-14 protocol identifier. Organizations that run highly visible websites should start trialing Google's SPYD module for Apache to assess the likely effects of HTTP/2 on their own infrastructure once it's officially formalized. There are also various servers and open source implementations available that can be used for testing.

As with any new technology or protocol, IT teams should follow relevant security forums to stay abreast of any developments, as well as pick up tips on how others are integrating HTTP/2 into their environment.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.

Next Steps

Gain insight into what HTTP/2 means for data center security

Learn more about HSTS and HTTPS

This was last published in April 2015

Dig Deeper on Web browser security