roots / trellis

WordPress LEMP stack with PHP 8.2, Composer, WP-CLI and more
https://roots.io/trellis/
MIT License
2.49k stars 608 forks source link

Bug: TLS 1.3 not working #1475

Open LucasDemea opened 1 year ago

LucasDemea commented 1 year ago

Terms

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 https://github.com/roots/trellis/blob/c9fa84141c6bca35515bdeddaa71b64e1a04bce5/roles/wordpress-setup/templates/no-default.conf.j2#L16-L23

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 commented 1 year ago

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 https://github.com/roots/trellis/pull/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 commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

Ubuntu 20.04: OpenSSL 1.1.1f 31 Mar 2020 😞

I think we need 1.1.1h at least

strarsis commented 3 weeks ago

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.