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?