Giters

h5bp / server-configs-nginx

Nginx HTTP server boilerplate configs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Improve SSL/TLS grade

midzer opened this issue · comments

commented

Hello,

with current v5 release I could "only" achieve an A ranking on https://www.ssllabs.com/ssltest/

Here's what I did to get an A+

  1. Enable OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

(I wonder why tls/ocsp_stapling.conf is not included somewhere, or am I overlooking something?)

  1. Change to
ssl_prefer_server_ciphers off;

in tls/ssl_engine.conf

  1. Replace cyphers
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;

in tls/policy_strict.conf

All necessary tested an taken from https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1k&guideline=5.6

Have a nice week
midzer

commented

Thanks for opening this issue, @midzer.

  1. As you noted, OCSP activation is available with h5bp/tls/ocsp_stapling.conf. Usage is as simple as include, and not done by default, as it requires some care with DNS and imply understanding of the impact of OCSP.
  2. ssl_prefer_server_ciphers off is the default value.
  3. Are you certain this list is not just the long names of the current list?

At the end, I'm not very sure what is your point here.
TLS perfection without configuration is almost impossible, and yet we are very close as far as I understand.

commented 
1. Enable OCSP stapling

@LeoColomb What's the issue with DNS? Or are you mixing it up with HSTS or something?
If you setup a certificate with certbot or similar, OCSP stapling should just work and shouldn't cause an issue, as far as I'm aware. I'd default to enabling this, unless I'm missing something.

The only thing I'd recommend not doing, is adding must-staple to the certificate, as nginx can't really handle that properly without some custom configuration.

2. Change to `ssl_prefer_server_ciphers off;`

If you're going to configure the server to ensure that secure ciphers are used, this only reduces security.
This allows clients to select a weaker cipher from the list of supported ciphers, which an attacker might be able to take advantage of. Setting this to on helps ensure that a client connects with the most secure cipher supported.

ssl_protocols TLSv1.3;

Are there any known attacks against TLSv1.2 (I don't remember hearing anything, but I could have missed it)? I'm not sure it's worth disabling if it's still considered to be secure.
I'd want it to be as backwards-compatible as possible if it doesn't degrade security at all.

commented

Thanks for your comments, all.
@midzer Indeed, this makes sense on what to improve if needed, but your point is quite different from initial ones. Pull requests welcomed 👍

@Dreamsorcerer:

  • OCSP. To be honest, this is just what can be read from Nginx docs: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling
    And still, OCSP is great for internet facing servers, but not 100% of servers. Enabling it per default might be tricky, but I might be wrong too.
  • ssl_prefer_server_ciphers. I'm not sure to follow… Better on or off?
  • ssl_protocols. I second your comment.
commented 
* OCSP. To be honest, this is just what can be read from Nginx docs: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling
  And still, OCSP is great for internet facing servers, but not 100% of servers. Enabling it per default might be tricky, but I might be wrong too.

Yeah, it should just work if it has a regular public CA issued cert. If you want to support self-signed certs etc. then you probably want it disabled.

Given that the majority of users are going to have public certs, I'd probably want it enabled by default with instructions for self-signed users to disable it, but that might cause backward-compatibility issues for self-signed users upgrading the template.

Maybe just ensure that part of the setup documentation has a list of recommended actions at the end, something like:

We recommend you:

  • Enable ssl_stapling in ... unless you are using self-signed certificates.
* `ssl_prefer_server_ciphers`. I'm not sure to follow… Better `on` or `off`?

on.

We have configured the ciphers to be secure here, and presumably with the most secure ones listed first.
Whereas >99.9% of users are not going to have configured the ciphers on their clients, and many clients include less secure ciphers for compatibility.
So, preferring the server ciphers can marginally improve security.

Clients still have ways to overrule this if they really want to choose specific ciphers (e.g. by only sending 1 available cipher at a time, and retrying the connection until they find a supported one). Another example, is my SSH client is configured to accept about 1 cipher only, and then has a whitelist to use other ciphers with specific hosts who don't support it.

commented

Ok great, thanks!
Again, definitely open to pull requests. One per change/topic would be the best.

  • OCSP
  • ssl_prefer_server_ciphers
  • ssl_protocols (?)
commented

To keep things simple for this excellent config framework, keeping on is the best safe choice to avoid confusion or misconfiguration; however, off is arguably the best configuration choice for modern configurations when using only TLS 1.2 + 1.3 or only 1.3. It doesn't affect security, but adds minor client-side preference options.

Using the Mozilla SSL Configuration Generator (https://ssl-config.mozilla.org) as a guide, if you choose Modern or Intermediate, the reason it's off there is because only TLS 1.2 and 1.3 are allowed. None of the ciphers are considered weak, so letting the client choose the best one is preferred based on its needs.

If you needed the Old configuration for legacy reasons and protocols like TLS 1.0 or 1.1, only then would you set ssl_prefer_server_ciphers to on to prevent the client from making really dumb choices (although none of them are really great).

More explained in the Rationale sections here: https://wiki.mozilla.org/Security/Server_Side_TLS

commented

Great, thanks for this clarification @avj!
I'd be happy to keep the modern config strict and as “the best”.
If off is arguably the best configuration, a pull request is very welcome! 🙂

commented

Didn't think about the possibility of the client choosing a cipher based on hardware acceleration. So, I guess as long as you consider the weakest cipher to still provide good security, then it's not really an issue to switch it to 'off' and can provide a performance improvement to clients.