Resolved nginx HTTP/2 support cipher problems

[bulent]

Hi,
I have B rating because of:
This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.
What I have to do to have A grade

 

[Ankebut]

check this here
https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

 

[Lloyd_mcse]

Hi,
I have B rating because of:
This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.
What I have to do to have A grade

You'll need to generate a new dhparam...

openssl dhparam -out /etc/nginx/dhparam.pem -5 2048

And add it to your Nginx ssl.conf...

ssl_dhparam   /etc/nginx/dhparam.pem;

I hope that helps
Regards

Lloyd

 

[bulent]

Thanks @Lloyd_mcse

I will check that later.

 

[Ankebut]

@Lloyd_mcse what is here better 2048 or 4096 generated key? give here performance differences?

 

[Lloyd_mcse]

@Lloyd_mcse what is here better 2048 or 4096 generated key? give here performance differences?

Hi Ankebut,
there is a performance overhead using a 4096bit dhparam, I did some testing a couple of years ago with dhparams of different sizes and SSL Certificates of diifferent sizes, and found it best to match the size with the SSL Certificate public key size...according to the ssllabs test.
https://community.qualys.com/thread/12667

4096Bit Public Key + 4096Bit DH = 100
2048Bit Public Key + 2048Bit DH = 90
2048Bit Public Key + 4096Bit DH = 90

Obviously not performance, but should help you decide what size to use.
Regards

Lloyd

EDIT: I wrote a post on my blog at the time, with dh directives for other servers - courier, dovecot etc. https://www.lloyd-day.me/creating-dh-parameters/

 

[trialotto]

@Lloyd_mcse what is here better 2048 or 4096 generated key? give here performance differences?

@Ankebut,

This question is not easily answered, since a lot of the relevant context is missing.

In general, it is not about 2048 or 4096 bit keys, even though one thing is clear: the 4096 is associated with a (small) performance penalty AND a higher test grade on ssllabs.com.

However, the context consists of much more than the key itself, amongst others:

a) using a Apache + Nginx stack (or a stand-alone Nginx), with the major points of concern being

1 - Nginx can be very secure with HSTS, OCSP and DHE and so on, but this does not say anything about the Nginx to Apache connection: Nginx directives secure Nginx (not Apache),
2 - Apache is accessible from the outside: Apache can be directly accessed, in the sense that the Nginx proxy can be bypassed, implying that a secure Nginx can become ineffective,

but the general advantage of the Apache + Nginx stack is that can apply less strict settings for the Apache to Nginx connections, as long as Nginx is secure enough.

And with respect to the point of concern involving the direct access to Apache (see point 2 above), one can mitigate this problem by simply using caching mechanisms and/or settings that allow (on the one hand) browser caching and/or (on the other hand) direct serving of static files via Nginx.

b) the key generator should be secure: the latest and patched OpenSSL version should be used to generate any key, irregardless whether they are 1024, 2048 or 4096 bit keys.

In general, any non-patched version of OpenSSL can still cause security vulnerabilities, so there is a necessity to use keys generated with patched OpenSSL versions.

Note that the same applies to the OpenSSL version, used at compilation time of Nginx: the Nginx binary can be a security risk, if a non-patched OpenSSL version has been used.

c) use 4096 bit Diffie-Hellmann Ephemeral (DHE) keys, if and whenever possible.

For a very rough explanation, see the relevant part in the article https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

Note that DHE keys are very valuable: any security vulnerability becomes mitigated when using DHE, so this is rather convenient if a patch is not yet available.

d) the most important aspect is the CIPHER SUITE: make it as strict as possible.

Note that the current cipher suites in Plesk has been improved (compared to previous ones), but it is still not strict enough: there are some redundant cipher suites and some very low grade cipher suites, implying that some vulnerability is still present.

e) use secure applications and/or links: it does not make any sense to secure the server, while in the meantime using applications that are a security blackhole.


Well, to summarize all of the above in rough outlines:

- just use the Nginx as a secure proxy: reduce the attack surface by increasing the security of Nginx to the maximum level,
- just use some caching mechanisms or server static files via Nginx: keep traffic away from Apache, if and whenever possible,
- check and re-check the cipher suites: in essence, it is or should become a recurring task, to keep the cipher suites up-to-date and secure,
- be aware of the common pitfalls: keep track of issues with OpenSSL, see the gaps in the design structure of the stack used and so on,

and the above contains some general rules to create some good practice.


And, to answer your question "which key is better?" in short: the 4096 bit DHE key (and the penalty on performance is negligible).


Hope the above helps....

Regards....

 

[urki]

@trialotto,

about cipher suites, I am sure you are already aware of the site https://cipherli.st/ (also made my Remy) which seems to list strong ciphers for most web servers and also other software. Not sure about how often it gets updated though.

I would like to get your feedback about the site and ciphers it lists, or if possible, your sources on updated cipher lists (or just a cipher suite(s) you use), if any.

 

[Ankebut]

EDIT: I wrote a post on my blog at the time, with dh directives for other servers - courier, dovecot etc. https://www.lloyd-day.me/creating-dh-parameters/

Hello @Lloyd_mcse can you please say me in witch folder and file we add the directives on server Plesk Onyx with debian?

 

[UFHH01]

Hi Ankebut,

you might like the following idea/suggestion:

On our servers, we create weekly, new DH - params inside the folder "/etc/dhparams/" and rsync the new files with the depending folders ( "/etc/apache2/" - "/etc/nginx/" - /etc/postfix/ - "/etc/dovecot/" ), but you are as well able to use the very same folder "/etc/dhparams/" for all these services, because these services use the very same "group/owner = root" for the folders and files.

Command for the weekly cronjob ( user "root" ):

FILE=`mktemp` ; openssl dhparam 512 -out $FILE && mv -f $FILE /etc/dhparams/dhparam512.pem && FILE=`mktemp` ; openssl dhparam 1024 -out $FILE && mv -f $FILE /etc/dhparams/dhparam1024.pem && FILE=`mktemp` ; openssl dhparam 2048 -out $FILE && mv -f $FILE /etc/dhparams/dhparam2048.pem && FILE=`mktemp` ; openssl dhparam 4096 -out $FILE && mv -f $FILE /etc/dhparams/dhparam4096.pem

You may certainly replace each creation - command ( starting with "openssl dhparam XXXX" ) with with suggestions from @Lloyd_mcse article - link, but you would leave out the file - name, because the file - name will be passed over to the command "mv -f $FILE /etc/dhparams/dhparamXXXX.pem".​

​

Command for the additional cronjob to rsync the dhparams ( user "root" ):

rsync -r /etc/dhparams/* /etc/apache2 && rsync -r /etc/dhparams/* /etc/nginx && rsync -r /etc/dhparams/* /etc/postfix

​

You asked as well for locations and definitions inside the depending configuration files... here you go ( based on the above "rsync" - command ) :

For postfix - up to version "3.1.0" ( /etc/postfix/main.cf ):

Pls. note: Maximal usage is "2048" - bits for DH - param - keys and postfix only knows and understand the settings "smtpd_tls_dh512_param_file" and "smtpd_tls_dh1024_param_file" ( pls. see postfix documents at: => http://www.postfix.org/FORWARD_SECRECY_README.html - consider to equal the bits - size for your DH - param - key with the ones from the used SSL - certificate. )

...
smtpd_tls_dh512_param_file = /etc/postfix/dhparam512.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dhparam2048.pem
...

​

For Dovecot - version "2.2" ( /etc/dovecot/dovecot.conf ):

Pls note: Dovecot has a "built-in" - feature and generates it's own DH - param - key. The setting should be already included in your configuration file.

ssl_dh_parameters_length = 2048

​

For QMAIL ( /var/qmail/control/ssl ):

DHFILE="/var/qmail/control/ssl/dh2048.pem"

​

For Courier-IMAP ( "/etc/courier-imap/imapd-ssl" + "/etc/courier-imap/pop3d-ssl" ) :

TLS_DHPARAMS=/etc/courier-imap/dhparam2048.pem

​

For apache ( "/etc/apache2/conf-enabled/dhparams.conf" ) :

Pls. note: You might already have own, unique configuration files, either located at "/etc/apache2/conf.d/ - "./conf-enabled/ ( symlinks from "./conf-available/" ( or "/etc/httpd/..." on CentOS/RHEL - based systems ), so either consider to use one of your own, unique configuration files, or create one ( you see that I used the example "/etc/apache2/conf-enabled/dhparams.conf" with the content:

SSLOpenSSLConfCmd DHParameters "/etc/apache2/dhparam2048.pem"

​

For NGINX ( "/etc/nginx/conf.d/dhparams.conf" ) :

Pls. note: You might already have own, unique configuration files, either located at "/etc/nginx/conf.d/" , so either consider to use one of the own, unique configuration files, or create one ( you see that I used the example "/etc/nginx/conf.d/dhparams.conf" with the content:

ssl_dhparam /etc/nginx/dhparam2048.pem;

 

[Ankebut]

great thx.

 

[Ankebut]

@UFHH01 i have add this to my new server cronjob that creat the files but all pem files is empty? any idea?
Shedule Task say all ok but the files on server is empty.

FILE=`mktemp` ; openssl dhparam 512 -out $FILE && mv -f $FILE /etc/dhparams/dhparam512.pem && FILE=`mktemp` ; openssl dhparam 1024 -out $FILE && mv -f $FILE /etc/dhparams/dhparam1024.pem && FILE=`mktemp` ; openssl dhparam 2048 -out $FILE && mv -f $FILE /etc/dhparams/dhparam2048.pem && FILE=`mktemp` ; openssl dhparam 4096 -out $FILE && mv -f $FILE /etc/dhparams/dhparam4096.pem

Command for the weekly cronjob ( user "root" ):

 

[Penguin-IT]

Hi Ankebut,

you might like the following idea/suggestion:

On our servers, we create weekly, new DH - params inside the folder "/etc/dhparams/" and rsync the new files with the depending folders ( "/etc/apache2/" - "/etc/nginx/" - /etc/postfix/ - "/etc/dovecot/" ), but you are as well able to use the very same folder "/etc/dhparams/" for all these services, because these services use the very same "group/owner = root" for the folders and files.

Command for the weekly cronjob ( user "root" ):

FILE=`mktemp` ; openssl dhparam 512 -out $FILE && mv -f $FILE /etc/dhparams/dhparam512.pem && FILE=`mktemp` ; openssl dhparam 1024 -out $FILE && mv -f $FILE /etc/dhparams/dhparam1024.pem && FILE=`mktemp` ; openssl dhparam 2048 -out $FILE && mv -f $FILE /etc/dhparams/dhparam2048.pem && FILE=`mktemp` ; openssl dhparam 4096 -out $FILE && mv -f $FILE /etc/dhparams/dhparam4096.pem

You may certainly replace each creation - command ( starting with "openssl dhparam XXXX" ) with with suggestions from @Lloyd_mcse article - link, but you would leave out the file - name, because the file - name will be passed over to the command "mv -f $FILE /etc/dhparams/dhparamXXXX.pem".​

​

Command for the additional cronjob to rsync the dhparams ( user "root" ):

rsync -r /etc/dhparams/* /etc/apache2 && rsync -r /etc/dhparams/* /etc/nginx && rsync -r /etc/dhparams/* /etc/postfix

@Ankebut

This script and the line for cron, that Ankebut posted might not work, because the openssl command is in the wrong order. The number of bits must come after the options. What @Lloyd_mcse wrote here has the correct order. It seems sometimes it works, sometimes it doesn't, if using the wrong order with the options after the number of bits.