HTTP/2 promises better performance -- but with security caveats

No security problems have been found in the HTTP/2 protocol itself, it's worth waiting for everything to shake out

The new Internet communication protocol, HTTP/2, is now being used by 11 percent of websites -- up from just 2.3 percent a year ago, according to W3Techs.

The new protocol does offer better performance, but there is no particular rush to upgrade, and it's backwards-compatible with the previous protocol, HTTP/1.1.

No security problems have been found in the protocol itself, but there are vulnerabilities in some implementations and the possibility of lower visibility into internet traffic, so it's worth waiting for everything to shake out.

The pressure to switch is likely to come from lines of business, said Graham Ahearne, director of product management at security firm Corvil.

"They look to give their customers a faster, more responsive experience on their websites and e-commerce portals," he said.

But there are some nuances, with data volumes and new emerging vulnerabilities, that enterprises will need to keep an eye out for, he added.

"New is good, but also means unproven, which can lead to unanticipated exploitable exposures," he said.

The HTTP/1.1 protocol has been around for about 16 years, and is the underlying messaging standard for requesting web pages and associated resources. Requests go through one at a time, so some browsers use multiple connections to send parallel requests, which causes congestion. Web sites also use a number of tricks and workarounds to try to deliver content faster.

"It was pretty decent, but not really designed around performance," said Brett Mertens, senior product manager at Limelight Networks. "Now people are more concerned about performance."

[ ALSO ON CSO: Be wary of HTTP/2 on Web servers ]

HTTP/2 promises to address this problem with multiplexing, which especially benefits websites with lots of small objects.

"In a 1.1 world, a browser would open up four to six connections to a web servers to get the content," said Mertens. "In an HTTP/2 world, a single connection, multiplexed, understands the higher priority information to download, compresses the headers going back and forth, and all the communication is binary instead of clear text, so it's a more efficient process."

It doesn't look any different to the end user, he added, but the website might load a little faster.

Encryption not mandatory but still required

Mandatory encryption isn't built into the protocol itself. However, all current browser implementations require TLS encryption, adding a layer of security for the web.

"A lot of the security differences revolve around how it's been implemented more than the actual protocol itself," said Mertens. "Overall for security, it's a net positive and for performance it's a net positive, too."

But the encryption could be a double-edged sword for some companies, said Guy Guzner, CEO at security firm Fireglass.

"Look at all the security devices that exist between clients and servers -- web gateways, intrusion prevention devices, firewalls and so on -- they are supposed to analyze web traffic, and determine if it's malicious or not," he said. "My concern is that they're not adapted yet to HTTP/2."

That means that enterprises might no longer be able to effectively scan HTTP/2 traffic, both inbound connections that might be delivering malware and outbound connections exfiltrating critical data.

Some vendors are already offering solutions that work around HTTPS and SSL encryption, he said. But the changes that come with HTTP/2 are on a more fundamental level.

"It allows multiplexed sessions, and sending files as content and resources, that are difficult for the security product to reassemble and run through an anti-virus engine," he said. "They will lose the thread of the session and not be aware of the content that is going through."

Solving this problem isn't going to be easy. Vendors will have to update their products to handle HTTP/2, and there are a lot of products out there.

"And even if it's introduced in some updated version, sometimes customers don't want to upgrade -- sometimes the upgrade cycles can take years," Guzner said. "It can become a big security hole and it's a big concern."

He recommends that enterprise run tests first to see whether they are able to inspect HTTP/2 traffic with their current systems, and, if not, they might want to wait.

"Maybe they don't want to allow HTTP/2 just yet," he said. "Most of the internet is not supporting HTTP/2 yet, and even the sites that are, will fall back to HTTP/1.1. You can disable HTTP/2 and still experience the internet -- maybe without some of the performance gain, but at least it will be secure."

New vulnerabilities

HTTP/2 poses other risks to enterprises as well, beyond the issue of visibility into internet traffic. Several vulnerabilities have already been discovered, all related to distributed denial of service attacks. They include the Slow Read, the HPACK Bomb, the Dependency Cycle Attack, and the Stream Multiplexing Abuse vulnerability.

Security firm Imperva presented a report about HTTP/2 security vulnerabilities at Black Hat this summer.

The company reported all the vulnerabilities to vendors, and they have all been fixed, said Itsik Mantin, the company's director of security research.

"The protocol itself, the way HTTP/2 is explained and specified in the standard, is OK," he said. "There is no problem there. The problem is in the implementations."

Imperva looked the major web servers, including Apache, IIS, Jetty, Nghttpd and Nginx, and found that each one was vulnerable to at least one attack.

"In some cases, it is sufficient to just send a single request to crush the server," he said.

That means that attackers don't need an army of infected machines to act as relays or magnifying relays.

"You can mount an attack with a single laptop," he said.

And even though the vulnerabilities have all been fixed, it doesn't mean that all the Web servers have installed the patches.

"From what we know about the history of web servers, many servers are probably still unpatched," he said. "Patching has a cost. Owners have to know that there is a problem, they have to be notified, they have to get the patched version, evaluate the impact on their servers, so not all of them are rushing to install the patches."

For companies that need to upgrade to HTTP/2 and run their own web servers and can't keep the patches up to date, he suggested using a web application firewall that protects against the new vulnerabilities as they are discovered.

Most of the major vendors, he said, offer this functionality, as does Imperva.

Adoption moving along at a decent pace

Although 11 percent might seem like a low adoption rate, the new protocol is actually doing well given that HTTP/2 only came out in early 2015.

All the major PC and mobile browsers now support it.

So do many top websites, even though high-traffic sites tend to be operated by large, inertia-driven organizations, said Stephen Ludin, chief architect for Web experience engineering at Akamai Technologies.

"Some very large sites, like Google and Twitter, are all using HTTP/2," he said.

The main driver for upgrading is performance, he added.

"We have seen performance range from zero percent improvement to 30, 40 even 50 percent," he said. "The average is around 10 percent or so."

He also recommended that companies take their time before upgrading to HTTP/2.

"There's no need to flip the switch and one day switch over to HTTP/2," he said. "Do some A/B testing. Take your time."

Web site developers might want to work on architectural changes to take full advantage of HTTP/2, he added.

Companies that use CDN services like Akamai's and Limelight's get a leg up, since the CDN takes care of all the implementation details.

"Our participation alone has had a dramatically positive effect on HTTP/2 adoption," said Ludin. "We are the front end for our customers, so they don't need to do anything on their own to support HTTP/2. It's just a matter of going to your Akamai configuration and flicking it on."

He added that Akamai has been involved since the very early days of HTTP/2.

"We had early implementations of it and were one of the first CDNs to have it out there in the wild," he said.

Join the newsletter!

Error: Please check your email address.

More about Akamai TechnologiesApacheCSOGoogleImpervaTwitter

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Maria Korolov

Latest Videos

More videos

Blog Posts