Docker-nginx: ALPN support for HTTP/2

Created on 29 Mar 2016  ·  32Comments  ·  Source: nginxinc/docker-nginx

Would it be possible to include a OpenSSL version >= 1.0.2 to make ALPN work?
Due to the official documentation it's needed for HTTP/2 over TLS:

Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2.

The current version in the nginx:1.9.12 image is:

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

Most helpful comment

Done starting with nginx:1.13.0 / mainline and nginx:1.12.0 / stable for Debian-based images / latest.

All 32 comments

Note that HTTP/2 right now works via NPN, which does not require openssl 1.0.2 and most browsers still support it at the time of writing.

The support for ALPN will arrive in nginx:latest as soon as Debian Stretch with openssl 1.0.2 is released.
If you really need ALPN with nginx official, please use the alpine variant, as it has openssl 1.0.2.

Thanks a lot for the fast reply!
I will have a look at the alpine variant.

Starting May 15th, Chrome will drop support for SPDY and NPN [1].
Does this mean everyone wanting something better than HTTP/1.1 using this image should switch to the Alpine version?

[1] https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html

Not really, you can still use HTTPS.

I agree with this: https://plus.google.com/+AmbroosVaes/posts/TLJJ41Ghg9R

There does't seem to be any workaround for now except building OpenSSL ourselves (is it easy?) or switching to the Alpine variant (which is alien to most people).

I tried the Alpine version and HTTP/2 and ALPN are working. I only had to change the FROM instruction in my Dockerfile to reference an Alpine version.

@teohhanhui indeed. There are a lots of people with the same arguments like you linked, but apparently Google does not care at all (not that is surprising).

One of the workarounds for nginx could be using Ubuntu 16.04 as a base image, but I'm not really sure how much breakage that will cause - I would expect many people actually do FROM nginx:latest and use debian-specific things there. I'm also sure HTTP2 does not justify that breakage - after all, browsers will still show your website.

I was looking into this today and found out (by trial and error) that the alpine and debian versions differ in their end result due to this...

I would expect that nginx:1.10 and nginx:1.10-alpine wouldnt differ that much (i.e. the openssl-version) but it did... One might argue that since we're talking about an nginx image that both would lead to the same build...? (but smaller images et al) But due to differing openssl-versions the actual nginx build is also very different... (one supporting APLN whilst the other doesnt) that seems weird to me... (or atleast should be documented somewhere? i.e. which openssl version its built with i.e.)

(BTW this also seems to go for the built in modules enabled between the two versions of the image?)

Now that it's long past May 15th (I guess the switch to turn it off actually came a couple weeks after?), HTTP/2 is not working on a lot of sites where it was working...

Being a nice feature that has some nice performance gains on many sites, it'd be great if we could come up with a good solution for the official nginx image.

Having a community-audited image with the recommended version of OpenSSL seems like a very good idea. (Isn't that part of why Google dropped support for older versions?)

It looks like openssl-1.0.2 is available in jessie-backports. I'll have it running for a couple of weeks on my infra and then will consider it being included in the nginx official image.

Scratch that actually, as it will require nginx to be recompiled against backports version of openssl. Won't work.

Any update on this?

Use the Alpine variant. It's smaller too.

On 12 Dec 2016 02:31, "Foorack" notifications@github.com wrote:

Any update on this?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nginxinc/docker-nginx/issues/76#issuecomment-266298487,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhf6-DGwzSQ-_5HWHTvEygVN9wha_wVks5rHEGHgaJpZM4H68nw
.

The problem isn't just when we want to use nginx ourselves, but when we use tools built off of nginx or don't have as much options for the base image. We should be able to rely on the _main_ official image for things like this.

(An example is https://github.com/jwilder/nginx-proxy, which uses FROM nginx and thus doesn't support HTTP/2 out of the box.)

For jwilder/nginx-proxy, it's actually recommended(?) to use a setup with
separate containers for docker-gen and nginx.

On 12 Dec 2016 13:08, "Cameron Spear" notifications@github.com wrote:

The problem isn't just when we want to use nginx ourselves, but when we
use tools built off of nginx or don't have as much options for the base
image. We should be able to rely on the main official image for things
like this.

(An example is https://github.com/jwilder/nginx-proxy, which uses FROM
nginx and thus doesn't support HTTP/2 out of the box.)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nginxinc/docker-nginx/issues/76#issuecomment-266344491,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhf62g1ZKbTotZJrufEYc4-E74vk7hqks5rHNbqgaJpZM4H68nw
.

Stumbled across this today, found out http2 was broken on all our websites.

Would be great to add a footnote to the readme that only the -alpine version currently works with http2. Wouldn't mind a ubuntu:16.04 based version as well. I don't think it would break anything in my use cases.

Alpine nginx is not same as debian based. It can be shown that alpine has lower performance. I really don't see a reason why ubuntu can't be used.

OpenSSL 1.0.1 has security flaws too and leaving this image based on it causes many people install it without their knowledge. One more problem is silent http2 failure. You would not know until you check in Chrome network console.

I suggest either moving to ubuntu or compile nginx against OpenSSL 1.0.2. I request @thresheek to do something about it. Let's not keep http2 broken for so long just because of a dependency.

@adityapatadia can you elaborate which exact OpenSSL "security flaws" are present in this image? Thank you.

Also, I'm waiting for Debian 9 to be available in docker to use, then I'll mgirate this image to it.

https://www.openssl.org/news/secadv/20160922.txt this is one issue which is concerning. But I found that it also affects some version of 1.0.2.

I think only way is to always include latest openssl at build time if that is possible. If we want to be even more maverick, we can try https://en.wikipedia.org/wiki/S2n

A quick google search did not reveal much details about when will new Debian be released. Any specific reason why we don't move to Ubuntu?

@adityapatadia All of the security issues in that document are fixed in Debian (except the ones only affecting OpenSSL 1.1 of course), see http://metadata.ftp-master.debian.org/changelogs/main/o/openssl/openssl_1.0.1t-1+deb8u6_changelog . Yes, Debian does know how to handle security issues ;)

A quick google search did not reveal much details about when will new Debian be released.

No release date has been announced, but Debian 9 currently is in "FullFreeze", meaning it is in its final stage before release and they are busy fixing release critical bugs.
See also https://wiki.debian.org/DebianStretch

According to https://security-tracker.debian.org/tracker/CVE-2016-6304 and openssl package changelog in debian, it was fixed in 1.0.1t-1+deb8u4, around September 21, 2016 (so, one day after CVE was published). As far as I can see, we shipped deb8u5 in nginx:1.11.4 (which probably was rebuilt after those fixes went live, because 1.11.4 went out around 15 Sep 2016).

I also have to add that nginx does not allow SSL/TLS renegotiation, so this exact problem is moot since you could not exploit it at all with any version of openssl used, vulnerable or not.

Including openssl in the image is not possible, we're not able to replicate distributions work and track security issues of every involved project.

Yes, Debian does know how to handle security issues ;)

😄

@thresheek you know nginx better than I do :) I hope debian team releases the new version soon. I was just surprised like @mgcrea when I came to know that my sites are not using http2. I switched to alpine version for now.

Any9ne tried the 1.12 stable version?

@motss since it is built using stretch-slim as a base image, it will work nicely with http2.

EDIT: it is built using stretch.

Just tried on my production system. Things seem fine. It's using http2 in chrome. I think the issue can be now closed.

Why is latest behind stable? I know that no other tags other than latest have any real meaning in Docker, but it does seem odd and perhaps unintentional that latest is _behind_ something we're calling stable?

I can open a separate issue about this inquiry if desired.

Found the answer to my own question (mostly because I wasn't the only one confused by the naming). It ultimately led me here: https://www.nginx.com/blog/nginx-1-12-1-13-released/

When 1.13.0 will be released next week, latest will be updated to point to it. :-)

Yeah, figured that out eventually!

On Thu, Apr 20, 2017, 1:43 PM Konstantin Pavlov notifications@github.com
wrote:

When 1.13.0 will be released next week, latest will be updated to point to
it. :-)


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nginxinc/docker-nginx/issues/76#issuecomment-295903389,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeQ76w89uOYkMmDrQMzyntTZ69Ef0QKks5rx8N-gaJpZM4H68nw
.

Just curious if the Nginx 1.12 supports Brotli compression. It'd be nice if someone told me how to check it?

@motss, it does not: http://nginx.org/en/CHANGES-1.12

Done starting with nginx:1.13.0 / mainline and nginx:1.12.0 / stable for Debian-based images / latest.

Was this page helpful?
0 / 5 - 0 ratings