Chrome drops NPN support for HTTP/2, ALPN only

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, November 16, 2015

Follow me on Twitter as @mattiasgeniar

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).



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.