Chrome drops NPN support for HTTP/2, ALPN only

Mattias Geniar, Monday, November 16, 2015 - last modified: Wednesday, May 11, 2016

Update 23/11/2015: Chrome reverted the change, NPN is allowed again! More details below.
Update 14/02/2016: Chrome will, as of May 15th 2016, only support HTTP/2 via ALPN. NPN supported is dropped (source).
Update 11/05/2015: We're still doomed, Chrome is scheduled to release a new update on May 15th 2016 that switches from NPN to ALPN, requiring OpenSSL 1.0.2 in order to further support HTTP/2. More details below.

If this cryptic title doesn't mean much to you, let me rephrase it in more words: Chrome is switching to the newer Application-Layer Protocol Negotiation (ALPN) extension for TLS negotiation. ALPN requires at least OpenSSL 1.0.2. Right now, Red Hat Enterprise Linux, CentOS, Ubuntu and Debian only support up to OpenSSL 1.0.1.

Basically, Chrome just made it damn near impossible to run HTTP/2 on a Linux server without some serious OpenSSL hackery.

Update for accuracy: this isn't Chrome's "fault". If Linux distributions were to ship a more recent version of OpenSSl, this wouldn't be an issue at all. But the Chromium team making this decision does have its impact on the possible adoption rate of HTTP/2.

Update 19/11/2015: Chrome is considering supporting NPN again to avoid hurting the HTTP/2 adoption. Decision not yet final: Issue 557197: Enable HTTP/2 over NPN (with OpenSSL)..

They did it for good reason though. ALPN, or internet RFC 7301 (proposed by Google as well, by the way), adds actual benefits.

ALP is a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.

For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.
RFC 7301

ALPN is crucial for proper protocol negotiation in a world where HTTP/1.1 and HTTP/2 can both run on the same TCP port.

Firefox will still do HTTP/2 (as far as I'm aware) over the older protocol, NPN (Next Protocol Negotiation). But since NPN is being replaced by ALPN (both as a standard as well as by the TLS community in general) it's only a matter of time before Firefox drops support too.

Some reading material;

As of Chrome version 47, ALPN is the only protocol supported in HTTP2. If you've enabled HTTP/2 in Nginx, expect it to break again when Chrome 47 becomes the new generally available version (probably december 2015). For now, the "main" Chrome version (46 at the time of writing) still supports HTTP/2 on NPN.

Hat tip to @AmbroosV on Twitter for reporting this issue.

Update: NPN merged back in

In a recent discussion by the chromium team, they decided to merge NPN back in.

The next Chrome Canary build will support NPN again. This essentially means openssl 1.0.1 is sufficient to run HTTP/2, so you're safe again on a CentOS, Ubuntu or Debian installation.

In the long run, those distributions will need to upgrade to at least OpenSSL 1.0.2 to support the newer (and better) ALPN protocol.

I'm happy to see the Chromium team revert the change, even if it means it's a less optimal HTTP/2 implementation for them. The plus side is the HTTP/2 adoption rate can continue to climb, which makes the web a better place (TLS + less TCP/IP connections).



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

svenn Monday, November 16, 2015 at 18:34

I don’t understand, can’t we just install OpenSSL 1.0.2 on CentOS 7 ? (or is this like gcc library dependencys ?) If this is the case are they not killing HTTP/2 for the next 5-7 years ? Also I asume you are usung CentOS/RHEL in production, but Ubuntu/debian have a faster update cycle, so they can run it or ?

Reply


    Mattias Geniar Tuesday, November 17, 2015 at 11:12

    I don’t understand, can’t we just install OpenSSL 1.0.2 on CentOS 7 ? (or is this like gcc library dependencys ?)

    It’s exactly like the glibc thing. Current tools & daemons are compiled against (mostly) openssl 1.0.1e on CentOS. I’m not sure if those APIs and libraries are the same in openssl 1.0.2. If they are, then we can just upgrade the openssl package. If they’re not, all tools & daemons need to be recompiled against the later version of openssl.

    The tricky problem is: it’s hard to package openssl because of all its dependencies. You don’t know what you’ll break with a newer version. And since we’re talking crypto/tls, pretty much every tool has dependencies on openssl.

    If this is the case are they not killing HTTP/2 for the next 5-7 years ? Also I asume you are usung CentOS/RHEL in production, but Ubuntu/debian have a faster update cycle, so they can run it or ?

    Yes: they are. It’s not really their fault, if distros would pick up openssl faster. But granted, openssl 1.0.2 has only been released since January this year. For long-term distros like CentOS or Ubuntu’s LTS releases, openssl 1.0.2 is just too new.

    As far as I’m aware, only the new Ubuntu 16.x will ship with openssl 1.0.2. Debian and the likes also have openssl 1.0.1 packages. (but this is coming from a centos user, perhaps someone with more ubuntu/debian boxes can confirm?)

    Reply


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links