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

Move nginx ssl_protocols directive outside of server context into new parent http context #141

Open
gene1wood opened this issue Apr 20, 2021 · 2 comments

Comments

@gene1wood
Copy link
Collaborator

Currently the nginx template doesn't assert an http context and just contains server contexts.

In the template's server context we assert ssl_protocols

As mentioned in #76 the ssl_protocols directive is not actually specific to each vhost. According to https://trac.nginx.org/nginx/ticket/844

As soon as one host supports a protocol, all the other hosts support that protocol too (even if disabled)

So for clarity (that the ssl_protocols is not per vhost) how about we move it out of the server context and into a parent http context?

We see someone encountering this problem in #140

@HLFH
Copy link
Contributor

HLFH commented Dec 5, 2022

Thanks @gene1wood!

I have moved in /etc/nginx/nginx.conf all these ssl directives within the http context:

  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:10m;  # about 40000 sessions
  ssl_session_tickets off;

  ssl_dhparam /etc/nginx/ssl/dhparam_4096.pem;

  # intermediate configuration
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_ecdh_curve x25519:prime256v1:secp384r1;
  ssl_prefer_server_ciphers off;

ssl_ecdh_curve is now working and did not work in the server context.
Nginx documentation is flawed as they still reference both the support of the http and the server contexts for most of ssl directives.

Furthermore, as I have at least one self-signed TLS certificate, I prefer to keep the OCSP configuration within theserver context in a file named ocsp_params located within the root /etc/nginx configuration folder:

  # OCSP Stapling ---
  ssl_stapling on;
  ssl_stapling_verify on;

  resolver 9.9.9.9 valid=300s;
  resolver_timeout 5s;

At least ssl_protocols and ssl_ecdh_curve MUST be only located within the http context.

And read some interesting comment: #124 (comment).

@makhomed
Copy link

Nginx documentation is flawed as they still reference both the support of the http and the server contexts for most of ssl directives.

Nginx support both the http and the server contexts for most of ssl directives. Yes, this is true.

Ngixn documentation is not complete reference for all use cases, more information about correct nginx configuration located in nginx trac and nginx maillists.

At least ssl_protocols and ssl_ecdh_curve MUST be only located within the http context.

No! This is not true. ssl_protocols also can be located in the server context.

In different IP-based (or port-based) virtual servers are quite possible use different ssl_protocols.

You tries to set different ssl_protocols in name-based virtual
servers. This will not work, because OpenSSL fixes
protocol before the name is known. At the same time, in different
IP-based (or port-based) virtual servers are quite possible
use different ssl_protocols.

And read some interesting comment: #124 (comment).

Yes, this is my comment with detailed explain how ssl directives work in the nginx.

I copy text of that my message here:

This is not nginx bugs. Bugs are in your configuration and expectations.

  1. You tries to set different ssl_protocols in name-based virtual
    servers. This will not work, because OpenSSL fixes
    protocol before the name is known. At the same time, in different
    IP-based (or port-based) virtual servers are quite possible
    use different ssl_protocols.

More about this is here:

https://trac.nginx.org/nginx/ticket/676
https://mailman.nginx.org/pipermail/nginx/2014-November/045738.html

This and other nuances of applying configuration for name-based
virtual servers are documented here:

http://nginx.org/en/docs/http/server_names.html#virtual_server_selection

  1. As for TLSv1.3 Ciphersuites, their OpenSSL, apparently, too
    selects immediately when the connection is established, and accordingly
    it is pointless to set them in name-based virtual servers, it is necessary
    set in the default server.

nietzscheanic referenced this issue in NginxProxyManager/nginx-proxy-manager May 22, 2023
Instead of creating a dummy certificate, we can return an SSL protocol error, which will generate a descriptive error message in the browser.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants