Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ALPN support for HTTP/2 #76

Closed
mxmo0rhuhn opened this issue Mar 29, 2016 · 32 comments
Closed

ALPN support for HTTP/2 #76

mxmo0rhuhn opened this issue Mar 29, 2016 · 32 comments

Comments

@mxmo0rhuhn
Copy link

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
@thresheek
Copy link
Collaborator

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.

@mxmo0rhuhn
Copy link
Author

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

@hermansje
Copy link

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

@thresheek
Copy link
Collaborator

Not really, you can still use HTTPS.

@teohhanhui
Copy link

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

@hermansje
Copy link

hermansje commented Apr 18, 2016

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.

@thresheek
Copy link
Collaborator

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

@fruitl00p
Copy link

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

@CWSpear
Copy link

CWSpear commented Oct 18, 2016

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

@thresheek
Copy link
Collaborator

thresheek commented Oct 18, 2016

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.

@Foorack
Copy link

Foorack commented Dec 11, 2016

Any update on this?

@teohhanhui
Copy link

teohhanhui commented Dec 12, 2016 via email

@CWSpear
Copy link

CWSpear commented Dec 12, 2016

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

@teohhanhui
Copy link

teohhanhui commented Dec 12, 2016 via email

@mgcrea
Copy link

mgcrea commented Jan 5, 2017

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.

@adityapatadia
Copy link

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.

@thresheek
Copy link
Collaborator

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

@thresheek
Copy link
Collaborator

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

@adityapatadia
Copy link

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?

@phw
Copy link

phw commented Mar 17, 2017

@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

@thresheek
Copy link
Collaborator

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.

@adityapatadia
Copy link

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.

@motss
Copy link

motss commented Apr 20, 2017

Any9ne tried the 1.12 stable version?

@thresheek
Copy link
Collaborator

thresheek commented Apr 20, 2017

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

EDIT: it is built using stretch.

@adityapatadia
Copy link

adityapatadia commented Apr 20, 2017

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

@CWSpear
Copy link

CWSpear commented Apr 20, 2017

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.

@CWSpear
Copy link

CWSpear commented Apr 20, 2017

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/

@thresheek
Copy link
Collaborator

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

@CWSpear
Copy link

CWSpear commented Apr 20, 2017 via email

@motss
Copy link

motss commented Apr 21, 2017

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

@thresheek
Copy link
Collaborator

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

@thresheek
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests