Question Nginx (TLS 1.3 + Pagespeed) - Updating cipher list

[Dukemaster]

Hi,
today I updated ngx_pagespeed, it is running like a charm with TLS 1.3. But in Qualys ssllabs.com I discovered that the recent cipher list should also get an update.
Here is the cipher list in /etc/nginx/conf.d/ssl.conf

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;

Please, could somebody tell me and other user how the cipher list should look like after to prevend the weak ciphers. Normally the weak ciphers are no problem, but we want to be perfect...

Greets

 

[virtubox]

Hello,

currently I use this cipher suite in my ssl.conf :

       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM';
       ssl_prefer_server_ciphers on;
       ssl_session_cache shared:SSL:20m;
       ssl_session_timeout 15m;
       ssl_session_tickets off;
       ssl_ecdh_curve X25519:sect571r1:secp521r1:secp384r1;

 

[Dukemaster]

Hi @virtubox,
first of all thanks a lot. It's not the first time that you helped me by good ideas and help.
Why do you switch ssl_session_tickets off?
Greets

 

[virtubox]

Hello,

From Mozilla TLS Guidelines :

Session resumption is a very useful performance feature of TLS, but also carries a significant amount of risk. Most servers do not purge sessions or ticket keys, thus increasing the risk that a server compromise would leak data from previous (and future) connections.

More in-depth explanation : ImperialViolet - How to botch TLS forward secrecy

 

[nMLxTMJTZ]

but tls 1.3 work with plesk?

 

[virtubox]

but tls 1.3 work with plesk?

Only if you have compiled the lastest nginx relase from sources

 

[Dukemaster]

ssl_session_tickets off;

Hi @virtubox,
forgot to ask you something about your config.
Why do You disallow session tickets? I always set it to yes and allowed them.
Therefor you should keep in mind that my server is in an only-one environment, not multiple servers connected together.
I've read the interesting statement you linked to. I guess, you running more servers together, so it could be
also only important for your unique environment.

Another additional question I'm interested would be:
Isn't ssl_ecdh_curve secp384r1; enough, leading to the same result, why do you use the other curves?
But, i won't waste your time. It's only a lil discussing interesting things...

Lots of greets

 

[virtubox]

Hi @virtubox,
forgot to ask you something according to your config.
Why do You disallow session tickets? I always set it to yes and allowed them.
Therefor you should keep in mind that my server is in an only-one environment, not multiple servers connected together.
I've read the interesting statement you linked to. Perhaps, I guess, you running more servers together, so it could be
also only important for your unique environment.

Another additional question I'm interested would be:
Isn't ssl_ecdh_curve secp384r1; enough, leading to the same result, why do you use the other curves?
But, i won't waste your time. It's only a lil discussing interesting things...

Lots of greets

In fact, the issue with session tickets is the regeneration is only performed when the web server restart. So you can enable session tickets but it's recommended (according to the Mozilla TLS guidelines ) to implement restarts of web servers to make sure session tickets are regenerated.

About ssl_ecdh_curve directive, secp384r1 is probably enough but it's better (in my opinion) to add stronger curves and to keep secp384r1 only for compatibility with some web browsers. This way, each web browser will use the strongest curve it support.

 

[Dukemaster]

Hi @virtubox,
thank you very much for your kind and detailed explanation of my additional questions. Great to know the background of the configuration.
Then it's contra-productive (hope the translation is also used in English language) for user of ngx_pagespeed (+Redis!) like you and me. Because restarting nginx or apache too often could cause corrupted data. Also for other reasons. Then I will follow your recommendation.
But I will use only secp384r1 for the reason that I don't want the strongest curve that as much as possible people can access my sites/communities. Don't want to leave someone outside the door only for the reason that he or she has not so much money to buy the newest devices or use the latest modern browser. Never mind, this is only a personal decision. May be I'm wrong...
Lots of greets

 

[virtubox]

Hi @virtubox,
thank you very much for your kind and detailed explanation of my additional questions. Great to know the background of the configuration.
Then it's contra-productive (hope the translation is also used in English language) for user of ngx_pagespeed (+Redis!) like you and me. Because restarting nginx or apache too often could cause corrupted data. Also for other reasons. Then I will follow your recommendation.
But I will use only secp384r1 for the reason that I don't want the strongest curve that as much as possible people can access my sites/communities. Don't want to leave someone outside the door only for the reason that he or she has not so much money to buy the newest devices or use the latest modern browser. Never mind, this is only a personal decision. May be I'm wrong...
Lots of greets

You're welcome. But I do not use redis with ngx_pagespeed, because there is no benefit over memcached at the moment.
So I just mount pagespeed cache directory in RAM using tmpfs.

sudo mount -t tmpfs -o size=512M tmpfs /var/ngx_pagespeed_cache

But it seems my explanation about ecdh_curves wasn't really clear, because when you set the directive :

ssl_ecdh_curve X25519:sect571r1:secp521r1:secp384r1;

Web browser will use the strongest supported curve in the list.

If web browser support X25519 curves -> use X25519
otherwise try the next curve listed.


There is no compatibiliy issues with old web browsers

 

[Dukemaster]

Yes, absolutely right. I tried the same last year and mounted also pagespeed cache as tmpfs in RAM, but then I wanted to try Redis, which is great for two things. I can use it for the Woltlab Software as Cache too. Therefor I decided to get ngx_pagespeed out of Ram for having a better overview how effective each step is. But, after point 4 release of Ubuntu (today) the next days I thought about the ultimate test bringing all the good ideas together and test them. We will see.
Yes, your Qualys result looks fine, will give it a try and the community user will tell me for sure if they have problems by site access.