-
Notifications
You must be signed in to change notification settings - Fork 60
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
Explicitly set list of allowed TLSv1.3 ciphersuites for nginx Modern/Intermediate/Old configurations #124
Comments
first, TLS_AES_128_CCM_SHA256 is safe, there is no reason to forbid it outside of the fact it's much slower than Chacha or AES-GCM on big systems that being said, openssl upstream does disable both CCM ciphers by default, and I know of no environments that override it, so why exactly we need to specify those ciphers explicitly? |
If it much slower - this also is good reason to disable it by default.
Quote from Transport Layer Security version 1.3 in Red Hat Enterprise Linux 8 article:
And yes, TLS_AES_128_CCM_8_SHA256 is disabled by DEFAULT in the RHEL 8 crypto-policies setup. (and in LEGACY policy it disabled too) See
Check From security point of view - there is no reasons to enable TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 ciphers by default. It might be better to approach this question from the other side - what could be the real reasons for the modern web to leave enabled these two ciphers (TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256) ? You ask the reason for these two ciphers to be disabled?
|
yes, I'm familiar with my work :)
yes, that's what I said, if you don't mess with openssl settings, it will not advertise TLS_AES_128_CCM_8_SHA256 or TLS_AES_128_CCM_SHA256
no, I'm asking for a reason to explicitly disable them, when a). they have always been disabled |
There are many environments, where TLS_AES_128_CCM_SHA256 cipher is enabled by default. For example: RHEL 8, CentOS 8, CentOS Stream 8, Fedora Server 33, and so on.
I don't touch openssl settings, but TLS_AES_128_CCM_SHA256 is enabled by default, And many servers in the internet have TLS_AES_128_CCM_SHA256 cipher enabled by default,
Many operating systems have at least TLS_AES_128_CCM_SHA256 enabled by default. So we should explicitly enable in nginx 1.19.4 and above only required set of TLSv1.3 ciphers:
|
yes, in RHEL-8 TLS_AES_128_CCM_SHA256 is indeed enabled by default, my mistake, sorry but like I said, it's not an insecure cipher, and while it is slower, it's not very slow, on my machine I get over 1.2GiB/s for while yes, browsers don't enable CCM ciphers, web is not only pages viewed by humans, it's also APIs, APIs that can be used by IoT devices or over slow links finally, indeed CCM is another cipher suite, so you can argue it's increasing the attack surface, that being said it uses very little code in addition to GCM and Cacha20 ciphers, they all are AEAD constructs, used like a black box by the TLS layer TLS_AES_128_CCM_8_SHA256 being enabled on access.redhat.com seems like an oversight, I'll report it internally |
But why this cipher is disabled by default on google.com, youtube.com, microsoft.com and many other sites in the internet? Maybe for minimizing and reducing possible attack surface?
Are you sure, what a general-purpose server provides API for IoT devices in the internet? Many you know of such sites? Did you read recommendations from https://wiki.mozilla.org/Security/Server_Side_TLS page ? Modern compatibility Intermediate compatibility (recommended) Old backward compatibility Can you find recommendations to enable CCM ciphers on the https://wiki.mozilla.org/Security/Server_Side_TLS page ? As I understand, https://ssl-config.mozilla.org/ site should 1:1 reflect configuration recommendations from the wiki https://wiki.mozilla.org/Security/Server_Side_TLS @april, can you confirm, what https://ssl-config.mozilla.org/ site should 1:1 reflect configuration recommendations from the wiki https://wiki.mozilla.org/Security/Server_Side_TLS ?
Now you are arguing not with me, now you are arguing with https://wiki.mozilla.org/Security/Server_Side_TLS page. |
Yes, the two sites (SSL Configuration Generator, Server Side TLS) are a mirror of each other. That said, the SSL Configuration Generator generally doesn't manually set TLS 1.3 ciphers (nor do many servers allow it), so if CCM is enabled in the underlying crypto libraries for TLS 1.3, then it will get enabled on servers. It's not generally enabled by default for most systems, and there is not much reason to enable it by default. People whose clients are embedded systems with low-power ICs that lack crypto acceleration will know to enable it on both ends. This is a small enough group of people to not manually discuss it in a document for general purpose servers. |
yes, I'm familiar with the https://wiki.mozilla.org/Security/Server_Side_TLS page I'm saying that the omission of TLS 1.3 ciphers from ssl-config-generator is intentional, exactly because you can't really misconfigure TLS 1.3 server ciphers |
We also don't list CCM because we don't want people going out of their way to enable them when they're rarely needed. It's often not easy to do so, and by listing them it makes it seem mandatory. |
So, adding CCM ciphers to the list of recommended ciphers at the wiki https://wiki.mozilla.org/Security/Server_Side_TLS page is bad idea. So, at least with the issue mozilla/server-side-tls#279 situation is clear now.
This issue is only about nginx, not about other servers. nginx 1.19.4 and above allow to configure TLS 1.3 ciphers.
RHEL 8, CentOS 8, CentOS Stream 8, Fedora Server 33 - all these distros are enable TLS_AES_128_CCM_SHA256 by default.
That is reason why I am propose exlicitly enable by default in the nginx only recommended by https://wiki.mozilla.org/Security/Server_Side_TLS page ciphers. Directive ssl_conf_command added to nginx recently, and many people don't know how to configure TLSv1.3 ciphers in the nginx. Summary, known reasons why TLS 1.3 ciphers should be configured explicitly in the nginx:
Summary, known reasons why TLS 1.3 ciphers should NOT be configured explicitly in the nginx: None.
You remember TLS_AES_128_CCM_8_SHA256 enabled on the site access.redhat.com? |
There are reasons to not explicitly configure this in nginx:
tangentially: if you use RHEL 8, Fedora, or any of the derived distributions, you shouldn't specify cipher suites in the configuration files anyway, you should use cryptographic policies
both things can be true at the same time should you enable CCM_8 when you don't have a reason to? no I used "shouldn't use" instead of "MUST NOT use" deliberately |
This is true right now, because it is no known vulnerabilities in the CCM ciphers at the current moment of time. But can you guarantee that there are no vulnerabilities in the CCM ciphers and will never be found? Imagine that in the future some vulnerabilities will be found in CCM ciphers - disabling CCM ciphers will become important at that point in time, but can you then quickly change the settings on all servers connected to the Internet? Do you know the exact reason why the OpenSSL developers disabled CCM ciphers by default? Maybe this reason is important and it makes sense for us to take it into account? I google for "why CCM ciphers disabled by default" and found, what CCM ciphers has some disadvantages, compared to GCM ciphers:
"To minimize attack surface by default" - it is important reason, from my point of view. For older nginx versions this settings can be provided commented out with description, what this setting will work in nginx starting from version 1.19.4, something like this:
As I understand from the file May be you are talking about FIPS policy with OSPP module enabled to disable CCM ciphers? But FIPS policy disable TLS_CHACHA20_POLY1305_SHA256 cipher and OSPP module disable TLS 1.3 protocol - this is not desirable behaviour, so I can't use FIPS policy with OSPP module to disable CCM ciphers. Also I can't find NO-CCM policy module, so I can't use cryptographic policies for disabling CCM ciphers in nginx. As for me - it is far more simple just to put in the nginx config:
and as result - CCM cipher will be disabled and I can clearly see which ciphers are enabled for TLS 1.3 protocol in nginx. |
Finally, that made me get an A with 100/100/100 With TLS 1.2 enabled it will be an A+, but with less cipher strength... https://www.ssllabs.com/ssltest/analyze.html?d=stat.def0.de&hideResults=on |
Hello, It does not always seem possible to enforce TLS v1.3 and specific TLS v1.3 ciphers in Nginx. I think I may be running into two Nginx bugs, but I am not sure. This is Nginx 1.22.1 from the official Nginx mainline APT repo and OpenSSL 1.1.1n on Debian 11.
Has anyone else run into these issues? |
This is not nginx bugs. Bugs are in your configuration and expectations.
More about this is here: https://trac.nginx.org/nginx/ticket/676 This and other nuances of applying configuration for name-based http://nginx.org/en/docs/http/server_names.html#virtual_server_selection
|
@makhomed Thank you very much for the thorough explanation and pointers! I understand now my incorrect assumptions. I apologize for the slightly off-topic comment. |
Openssl have a different way to set ciphers for TLS 1.3. If you using ssl_ciphers with only TLS 1.3 nginx will fail to start. You need to use "ssl_conf_command Ciphersuites" command in nginx. I implement it that way that I check in the template if tls version is set to 1.3 if so use the new syntax. Links: https://forum.nginx.org/read.php?11,287698 mozilla/ssl-config-generator#124 https://wiki.openssl.org/index.php/TLS1.3
openssl has a different way to set ciphers for TLS 1.3. If you use ssl_ciphers while only having the TLS 1.3 protocol enabled, nginx will fail to start. This commit uses the "ssl_conf_command Ciphersuites" command in nginx instead. References: - https://forum.nginx.org/read.php?11,287698 - mozilla/ssl-config-generator#124 - https://wiki.openssl.org/index.php/TLS1.3
nginx starting from version 1.19.4 has ability to configure TLSv1.3 ciphersuites.
nginx directive ssl_conf_command documentation
nginx directive ssl_conf_command commit description
For example:
OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:
But last two as I understand are primarily for embebbed microcontrollers with low cpu power and low battery capacity and they are not very safe, and probabbly should be disabled by default for the Modern/Intermediate/Old nginx configurations.
Maybe it will be good idea to add such setting to Modern/Intermediate/Old configuration examples?
Maybe commented out for older nginx versions and not commented for versions of nginx 1.19.4 and above.
Directive
ssl_conf_command Ciphersuites
used in nginx for configuring TLSv1.3 ciphers.Directive
ssl_ciphers
used in nginx for configuring TLSv1.2/TLSv1.1/TLSv1/SSLv3/SSLv2 ciphers.This is OpenSSL library limitation, so this is the main reason, why we need two different directives for configuring set of nginx ciphers/ciphersuites.
The text was updated successfully, but these errors were encountered: