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

Bug: TLS 1.3 not working #1475

Open
5 tasks done
LucasDemea opened this issue Feb 20, 2023 · 4 comments · May be fixed by #1476
Open
5 tasks done

Bug: TLS 1.3 not working #1475

LucasDemea opened this issue Feb 20, 2023 · 4 comments · May be fixed by #1476
Labels

Comments

@LucasDemea
Copy link
Sponsor Contributor

LucasDemea commented Feb 20, 2023

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

{% 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

@LucasDemea LucasDemea added the bug label Feb 20, 2023
@LucasDemea LucasDemea linked a pull request Feb 20, 2023 that will close this issue
@swalkinshaw
Copy link
Member

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
Copy link
Sponsor Contributor Author

LucasDemea commented Feb 22, 2023

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
Copy link
Member

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
Copy link
Member

Ubuntu 20.04: OpenSSL 1.1.1f 31 Mar 2020 😞

I think we need 1.1.1h at least

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

Successfully merging a pull request may close this issue.

2 participants