Enable TLS v1.3 support in the default nginx config

[Kami]

We should update nginx config to support TLS v1.3 in addition to TLS v1.2.

Since we still support Ubuntu 16.04, we can't do that easily for the installer (we could make it worth, but it's not the effort and complexity at this point), but we should at least do it for the docker setup (via nginx config patch) to begin with.

That image and nginx version should work just fine with TLS v1.3.

[arm4b]

I believe the target is to deprecate Ubuntu 16.04 LTS after Adding Ubuntu 20.04 LTS.
If that happens in v3.5.0, the TLS change could be done directly in the st2 nginx conf.

[Kami]

Yeah, that would be ideal. The less places and patches we need to maintain the better.

[punkrokk]

@amanda11 @armab @Kami So our agreed upon outcome is the st2.conf file that defaults to TLS 1.3, and a note in the docs that explains that one can change it back to TLS v1.2?

[amanda11]

@punkrokk That's my understanding, but I've not been involved on the discussions prior to this.

[arm4b]

Yeah, I'm 👍 to add TLS 1.3 as and addition or default in nginx.conf. As I understand @Kami was +1 too.

We know that U16 doesn't work with nginx & TLS1.3, but we're removing Xenial in this release.

I don't know if we want to add

- ssl_protocols TLSv1.2;
+ ssl_protocols TLSv1.2 TLSv1.3;

or maybe

- ssl_protocols TLSv1.2;
+ ssl_protocols TLSv1.3;

and how it'll work in practice on other platforms across the OS fleet we support? Probably something to research.

@punkrokk @Kami what are your thoughts?
cc @StackStorm/maintainers @StackStorm/contributors

[Kami]

I thought @armab and I already discussed somewhere (can't find the PR atm) that sadly we can't do that yet since it's not just Xenial that doesn't support TLS v1.3 out of the box, but also Bionic and RHEL 7.

I suggested only supporting TLS v1.3 on distros which support it (aka ship with OpenSSL 1.1.1), but that would increase the complexity and make troubleshooting harder.

[punkrokk]

I think we could have the install script sed the file based on the distro. Eh? Shouldn’t cause any issues. Eg only update it on newer distros. JP Bourget / @punkrokk

…

On Jun 1, 2021, at 4:21 PM, Tomaz Muraus ***@***.***> wrote:  I thought @armab and I already discussed somewhere (can't find the PR atm) that sadly we can't do that yet since it's not just Xenial that doesn't support TLS v1.3 out of the box, but also Bionic and RHEL 7. I suggested only supporting TLS v1.3 on distros which support it (aka ship with OpenSSL 1.1.1), but that would increase the complexity and make troubleshooting harder, — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Kami]

That's definitely possible, but it's a question of how we want to handle that. Installer script is just one of the "consumers" of that config file (other consumers include ansible playbook, chef, docker, etc.).

I believe right now most of the installations methods just copy over that nginx.conf file without any modifications (IIRC, only outlier is docker stuff where we apply a patch which is already error prone and hard to maintainer).

And even if we go with that route, the question is how to do it - default to TLS v1.2 and TLS v1.3 in the ngix.conf and then inside installer script remove TLS v1.3 if openssl 1.1.1 is not present or similar...

[Kami]

@armab What's your take on^?

IIRC, you had the strongest opinion in the past about having multiple files / code paths in such scenarios (and IIRC, also @blag).

[arm4b]

@Kami Thanks for more context! That's pretty critical information.
I thought it just Ubuntu 16 in question.
Considering Ubuntu 18 and EL7 are also not TLS v1.3-compatible, I agree it doesn't worth the change.

The drift in the default installation environment would probably hit us back with different issues and community support. Something we tried to optimize before with an identical configuration across the OS fleet.

Security-aware users can modify their configs, or service providers can recommend their clients to do the TLS 1.3 and more security hardening best practices that are not part of the default st2 config.

It might be even a good separation of the roles that comes naturally?

[cognifloyd]

Does enabling TLSv1.3 support cause problems on EL7 / Ubuntu 18? Or will nginix just ignore the protocol it can't support?

st2/conf/nginx/st2.conf

Line 39 in 6e9306c

ssl_protocols TLSv1.2;

- ssl_protocols             TLSv1.2; 
+ ssl_protocols             TLSv1.2 TLSv1.3; 

edit: context - I just added TLSv1.3 on our EL7 host, and I don't see any errors.

[arm4b]

Good point 👍

I think at this stage it would be nice to check all the OSes we support with a fresh install and if modified nginx config @cognifloyd mentioned works, any issues in the logs, what are the installed SSL versions in the system and how TLS version fall-back works in practice.

[cognifloyd]

on my EL7 host, I have:

• nginx-1.19.10-1.el7.ngx.x86_64 from the nginx mainline repo (1.21.0 is available - I haven't updated).
• openssl-1.0.2k-21.el7_9.x86_64 from CentOS Updates repo (nginx rpm declares a dependency on this one)
• openssl11-1.1.1g-3.el7.x86_64 from EPEL 7 repo

No issues in any of the logs or the journal. It is serving the site just fine. And chrome says I'm connecting with TLSv1.2, which makes sense given the lack of TLSv1.3 support on EL7:

[Kami]

That may work if we still want to support TLS v1.2 in addition to TLS v1.3, but need to double check since I thought it will error out if the openssl version against which nginx is linked doesn't support TLS v1.3 (but that may only be the case if we only specify TLS v1.3).

Another thing is cipher list - if we want to harden the deployment based on the available ciphers which depend on the OpenSSL version we will likely also need to have a special handling for that.

Would also help if you can post the output against nginx -V, in your case it maybe works because you installed openssl 1.1.1 from EPEL repo, but then again you said you are using nginx from the main line repo which likely isn't compiled against openssl 1.1.1.

[cognifloyd]

It's using openssl 1.0.2k-fips

$ nginx -V
nginx version: nginx/1.19.10
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

[Kami]

OK, I confirmed it indeed works and falls back to a supported version and doesn't error on startup in case multiple versions are specific and some / one of them is not supported by nginx.

That's a good news since we can indeed just do ssl_protocols TLSv1.2 TLSv1.3.

[Kami]

Meaning we can include that in v3.5.0.