Bug: TLS 1.3 not working

[LucasDemea]

Terms

• I have read the guidelines for Contributing to Roots Projects
• This request is not a duplicate of an existing issue
• I have read the docs and followed them (if applicable)
• I have seached the Roots Discourse for answers and followed them (if applicable)
• This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

TLS1.3 is not working on one of my servers, with the current trellis ssl config.

For the context: it's a satispress server on a subdomain, eg https://satis.mydomain.com. This is preventing latest composer versions to access this server, as it requires http2, and http2 requires tls1.3

TLS1.2 is working fine.

The culprit config lines seem to be

trellis/roles/wordpress-setup/templates/no-default.conf.j2

Lines 16 to 23 in c9fa841

	{% if sites_use_ssl %}
	server {
	listen [::]:443 ssl default_server deferred;
	listen 443 ssl default_server deferred;
	ssl_reject_handshake on;
	}
	{% endif %}

If I comment it out, TLS1.3 works again.

I've read that for TLS1.3 to work, every server block needs to include the ssl configuration.
A simple fix could be to add

include h5bp/directive-only/ssl.conf;

to the no-default ssl conf, but I'm not sure of the implications.

Steps To Reproduce

Not sure, the issue could be specific to my setup (subdomain, etc..)

Expected Behavior

TLS1.3 works.

Actual Behavior

TLS1.3 is not offered, as a tool like https://geekflare.com/tools/tls-scanner shows.

Relevant Log Output

❯ openssl s_client -tls1_3 -connect satis.mydomain.com:443

CONNECTED(00000003)
40C7E6F9E47F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1584:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 257 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Qualys tests shows A+ grade, but in the detailed log, I can see that TLS1.3 is not offered.

Versions

1.20.0

[swalkinshaw]

By default nginx uses “ssl_protocols TLSv1 TLSv1.1 TLSv1.2”

So that makes sense why explicitly adding the TLSv1.3 value would fix it 🤔

The no-default site actually used to have that. See #1414 where I changed it to remove the need for a generated SSL cert. Did your propose fix work?

I'm not sure if include h5bp/directive-only/ssl.conf would force us to set a certificate. But CI passes which means Nginx at least doesn't have a configuration issue with it.

[LucasDemea]

My fix works in my case, with ssl enabled. Didn't get to try without ssl.

There is also this (from https://trac.nginx.org/nginx/ticket/2073):

That's a bug in OpenSSL, see #2071 for details. Consider either using certificates in the default server block even if they are not needed due to ssl_reject_handshake, or switching to a different SSL library.

[swalkinshaw]

Looks like that OpenSSL issue is resolved but I'd have to confirm what versions are on Ubuntu 20.04 + 22.04

I'd really rather avoid going back to the old way of having to generate a certificate. At least it's working for you so far 🤞

[swalkinshaw]

Ubuntu 20.04: OpenSSL 1.1.1f 31 Mar 2020 😞

I think we need 1.1.1h at least

[strarsis]

Do you experience this issue: That over HTTP/2 only one or two concurrent requests are made, e.g. viewing the media library thumbnail view and only one or two images are downloading sequentialls (disable cache in Chrome Dev Tools network tab for testing this)? I have this issue with one particular Trellis/nginx. This all somehow points to an issue with TLS/SSL (OpenSSL library used by nginx). (Related Discourse discussion).

Edit: After adding a further domain and re-provisioning the issue was resolved. Just forcing the certificate for the existing domains to regenerate alone did not resolve the issue.