Resolved Changing DH-key from 2048 to 4096

[learning_curve]

Still unsure about your answer to our last question about you using CryptCheck to check DH key size
i.e. How was your experience when using it?

You can use directly openssl via ssh to test your server ssl configuration:

openssl s_client -connect  yourplesk.server.ltd:8443

Okay we have tried this thank you, but for us, this is again confusing. What we actually get when running this, is lots of information yes, but all about the SSL certificate that we have in place covering Plesk. Useful, but as we know already, the SSL certificate itself only has a DH2048 encryption. In our example test results, this line is also included FWIW

Peer signing digest: SHA512
Server Temp Key: ECDH, P-521, 521 bits

but what exactly where you expecting us to see clearly using this and/or what is your own experience when using it?

About ECC, curves P-384 provide the same encryption than a RSA key of 7680 bits. So any ECDHE configuration will be better than a classic DHE configuration

Wow, that's a new area for us now. If this is correct; "any ECDHE configuration will be better than a classic DHE configuration" then what is the pupose behind us all including this coding in our setups?

TLSDHParamFile /etc/dhparam/dhparam4096.pem

From your statement, it appears unecessary to use both at the same time?
Or we have we completely misunderstaood your post?

I do not have any issue with the curves P-256 and P-384.

ssl_ecdh_curve X25519:P-521:P-384; #   new nginx releases
ssl_ecdh_curve secp521r1:secp384r1; #   normal nginx configuration
ssl_ecdh_curve secp384r1; # old version of nginx

^^ Understood

 

[virtubox]

Still unsure about your answer to our last question about you using CryptCheck to check DH key size
i.e. How was your experience when using it?

I use CryptCheck often without any issues. It's for me a really good alternative to ssllabs, without all marketing stuff.

But Plesk interface isn't display by the global nginx server, it's another service named sw-cp-server, and to edit sw-cp-server ssl configuration, you have to look in the file /etc/sw-cp-server/conf.d/ssl.conf.
That's why you only see a DH2048 bits dh key on CryptCheck when you test the port 8443.

If this is correct; "any ECDHE configuration will be better than a classic DHE configuration" then what is the pupose behind us all including this coding in our setups?

TLSDHParamFile /etc/dhparam/dhparam4096.pem

From your statement, it appears unecessary to use both at the same time?
Or we have we completely misunderstaood your post? ^^

Yes, you have the choice between DHE and ECDHE configuration. It's better to use elliptic curves, but it will require a lot of time to make SSL/TLS configuration standard change. For example, to be PCI -compliant a DH2048 bits key is enough.

We are still using TLSv1 & TLSv1.1 when TLSv1.2 has been release in 2008.
If you want to learn more about SSL/TLS and other security solutions on our web servers, I recommend you the blog of Scott Helme : Scott Helme

 

[learning_curve]

I use CryptCheck often without any issues. It's for me a really good alternative to ssllabs, without all marketing stuff

As we said earlier, in our experience, whilst some areas are nice and precise, others are not (eg some pages are only presented in French) and, it's not as clear compared to other test sites

But Plesk interface isn't display by the global nginx server, it's another service named sw-cp-server, and to edit sw-cp-server ssl configuration, you have to look in the file /etc/sw-cp-server/conf.d/ssl.conf That's why you only see a DH2048 bits dh key on CryptCheck when you test the port 8443

You appear to have completely missed out on a section / thread / process that covers this in lots more detail. We upgraded our own sw-cp-server as a result. Go HERE and please read the complete thread. You also would need to go back to the very start of this thread itself to see why the other thread was initiallly posted.

Yes, you have the choice between DHE and ECDHE configuration. It's better to use elliptic curves, but it will require a lot of time to make SSL/TLS configuration standard change.

This is the first time we've seen this statement written anywhere.
We're still dealing with the concept of "...one or the other, not both"

For example, to be PCI -compliant a DH2048 bits key is enough

Yes, that's right and more information and guidance is available in the standard Plesk documentation

We are still using TLSv1 & TLSv1.1 when TLSv1.2 has been release in 2008.
If you want to learn more about SSL/TLS and other security solutions on our web servers, I recommend you the blog of Scott Helme : Scott Helme

We only use TLSv1.2 and have done since we started with Plesk. Once Plesk release an updated sw-nginx (or we compile our own....) which uses a later nginx release i.e. one that suports TLSv1.3, then we'll switch to that as it will be backward compatible with TLSv1.2 as well. Scott Helme we do refer to regularly and you're right, it's very helpful, but we also check elsewhere too Later on, we'll go and look further into the previously mentioned concept of "...one or the other, not both"

 

[virtubox]

As we said earlier, in our experience, whilst some areas are nice and precise, others are not (eg some pages are only presented in French) and, it's not as clear compared to other test sites

I agree about the very simple design and there are no translation. The easiest is to use observatory.mozilla.org, which include almost all security analyzers available.

You appear to have completely missed out on a section / thread / process that covers this in lots more detail. We upgraded our own sw-cp-server as a result. Go HERE and please read the complete thread. You also would need to go back to the very start of this thread itself to see why the other thread was initiallly posted.

Sorry but it's not really easy to answer to a multi-quote message, and I have answered to the wrong part.

This is the first time we've seen this statement written anywhere.
We're still dealing with the concept of "...one or the other, not both"

You can use ECDHE and DHE together in your configuration to support very old browser (ECDHE before DHE to allow compatible browser to use it).

ECDHE is faster and provide at least the same security than RSA keys. Currently with my configuration, only Windows XP and Android <4.3 browser are not able to access to my websites, and for example Google web servers do not use DHE at all.

The best article I have read about this is only available in french, I will try to translate it . But I have found some old articles about ECDHE usage, :
About performance : SSL/TLS & Perfect Forward Secrecy | Vincent Bernat
About browser support : SSL Labs: Deploying Forward Secrecy