神刀安全网

The day Google Chrome disabled HTTP/2 for nearly everyone: May 15th, 2016

The Chromium project (whose end result is the Chrome Browser) has switched the negotiation protocol by which it decides whether to use HTTP/1.1 or the newer HTTP/2 on May 15th, 2016 .

That in and of itself isn’t a really big deal, but the consequences unfortunately are. Previously (as in: before May 15th, 2016), a protocol named NPN was used — Next Protocol Negotiation . This wasn’t a very efficient protocol, but it got the job done.

There’s a newer negotiation protocol in town called ALPNApplication-Layer Protocol Negotiation . This is a more efficient version with more future-oriented features. It’s a good decision to switch from NPN to ALPN, there are far more benefits than there are downsides.

However, on the server side — the side which runs the webservers that in turn run HTTP/2 — there’s a rather practical issue: to support ALPN, you need at least OpenSSL 1.0.2 .

So what? You’re a sysadmin, upgrade your shit already!

I know. It sounds easy, right? Well, it isn’t. Just for comparison, here’s the current (May 2016) state of OpenSSL on Linux.

Operating System OpenSSL version
CentOS 5 0.9.8e
CentOS 6 1.0.1e
CentOS 7 1.0.1e
Ubuntu 14.04 LTS 1.0.1f
Ubuntu 16.04 LTS 1.0.2g
Debian 7 (Wheezy) 1.0.1e
Debian 8 (Jessy) 1.0.1k

As you can tell from the list, there’s a problem: out of the box, only the latest Ubuntu 16.04 LTS (out for less than a month) supports OpenSSL 1.0.2.

Upgrading OpenSSL packages isn’t a trivial task, either. Since just about every other service links against the OpenSSL libraries, they too should be re-packaged (and tested!) to work against the latest OpenSSL release.

To give you an idea of the scope of such an operation, on a typical LAMP server (the one powering the blogpost you’re now reading), the following services all make use of the OpenSSL libraries.

$ lsof | grep libssl | awk '{print $1}' | sort | uniq anvil fail2ban gdbus gmain httpd postfix mysqld NetworkManager nginx php-fpm puppet sshd sudo tuned zabbix_agent

A proper OpenSSL upgrade would cause all of those packages to be recreated too. That’s a hassle, to say the least. And truth be told, it probably isn’t just repackaging but potentially changing the code of each application to be compatible to the newer or changed API’s in OpenSSL 1.0.2.

Right now, the proper way to run HTTP/2 on a modern server (that isn’t Ubuntu 16.04 LTS) would be to run a Docker container, based on Ubuntu 16.04, and run your webserver inside of it.

I don’t blame Google for switching protocols and evolving the web, but I’m sad to see that as a result of it, a very large portion of Google Chrome users will have to live without HTTP/2, once again.

Before May 15th, 2016 — a Google Chrome user would see this in its network inspector:

The day Google Chrome disabled HTTP/2 for nearly everyone: May 15th, 2016

After May 15th, it’ll be old-skool HTTP/1.1.

The day Google Chrome disabled HTTP/2 for nearly everyone: May 15th, 2016

It used to be that enabling HTTP/2 in Nginx was a very simple operation, but in order to support Chrome it’ll be a bit more complicated from now on.

This change also didn’t come out of the blue: Chrome had disabled NPN back in 2015 but quickly undid that change when the impact was clear. We knew, since the end of 2015, that this change was coming — we were given 6 months time to get support for ALPN going, but by the current state of OpenSSL packages that was too little time.

If you want to keep track of the state of Red Hat (Fedora, RHEL & CentOS) upgrades, here’s some further reading: RFE: Need OpenSSL 1.0.2 .

As I’m mostly a CentOS user, I’m unaware of the state of Debian or Ubuntu OpenSSL packages at this time.

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » The day Google Chrome disabled HTTP/2 for nearly everyone: May 15th, 2016

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址