the certificate information needs to inform about an outdated version

[janwillemstegink]

If a problem on internet.nl like this exists:
Affected parameters Status
DH-2048 insufficient
DH-2048 insufficient

For example, in control panel DirectAdmin for a Let's Encrypt certificate:
The creation key type EC384 for Let’s Encrypt created manually, can get renewed after 60-90 days with outdated RSA4096.
Solution: Automatic renewal without this file from the past: example.com.san_config.

Suggested functionality for internet.nl:
The certificate information may inform about an outdated version.

[bwbroersma]

Do you mean RSA4096 should be marked as outdated? Note that NCSC-NL - IT Security Guidelines for Transport Layer Security (TLS) is followed and currently RSA of at least 3072 bits are considered 'good'. Note that the NCSC-NL TLS guidelines are currently being updated, so what is considered 'good' may change in the near future.

[janwillemstegink]

The algorithm is really not yet clear on internet.nl. DH-3072 is already insufficient on internet.nl. See attachment of three pages in Word. It will have to become clear to administrators in some way that a config file can get in the way. Or an inadequately generated annual certificate.

key size.docx

See also eg RSA 2048 at your mail supplier:
https://internet.nl/site/prolocation.nl/2521735/#
https://www.sslcheck.nl/prolocation.nl

[baknu]

See the test explanation (e.g. on https://en.internet.nl/site/example.nl/2522386/#control-panel-14):

DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange depends on the lengths of the public and secret keys used within the chosen finite field group. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'.

So, note that when Diffie-Hellman Ephemeral is used for key exchange that Internet.nl checks if the key length is okay AND if a predefined finite field group specified in RFC 7919 is used. This is based on NCSC's IT Security Guidelines for Transport Layer Security (TLS)

Thus having a DH key length of >=3072 is SUFFICIENT but only if the predefined finite field group is used. And having a key length of 2048 is PHASE OUT, but only if the predefined finite field group is used. If no predefined finite field group for DHE is used, then the verdict will always be INSUFFICIENT.

[bwbroersma]

Also note: the choice in keys: RSA or EC will influence the Key Exchange!
See:

$ openssl ciphers -v aRSA | grep Kx=DH  
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(256) Mac=AEAD
DHE-RSA-AES256-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(256) Mac=AEAD
DHE-RSA-ARIA256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=ARIAGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(128) Mac=AEAD
DHE-RSA-AES128-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(128) Mac=AEAD
DHE-RSA-ARIA128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=ARIAGCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA256
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1

While:

$ openssl ciphers -v aECDSA
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-ARIA256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=ARIAGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-ARIA128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=ARIAGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(256) Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-NULL-SHA    TLSv1 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1

Only returns Key Exchange Elliptic-curve Diffie–Hellman (ECDH), so this will likely not have the weak key issues that DH has. Also there currently is an issue with ECDH curve checking:

• Key exchange parameters subtest: check for the exact ECDHE curves #972

[janwillemstegink]

The precise way of testing may improve. Thanks for the detailed explanation.
Anyhow, DH-3072 if insufficient on internet.nl, can easily be resolved with a proper certificate.

My point is that an administrator needs to much knowledge to retrieve the used algorithm with eg https://www.sslcheck.nl/.
Internet.nl cannot delete a config file from the past. And annual certificates are in practice generated with an outdated algorithm.

Auditing requires information about a wrongly generated certificate. Internet.nl may point to the solution of a better algorithm.
A test result like https://internet.nl/site/prolocation.nl/2525587/#control-panel-14 indicates misunderstanding.

[bwbroersma]

There is no reason to advise users EC over RSA, because RSA in some configurations has insufficient exchange parameters. The advise of Internet.nl follows the NCSC-NL guidelines.

A nice find that ProLocation should indeed use at least ffdhe3072 instead of some self generated DH-2048. It would be nice to give some sample nginx/apache openssl config that does comply, but https://ssl-config.mozilla.org/ is already pretty clear to use defined ffdhe.

[bwbroersma]

The question is: should a sub-test (without points) be created for EC certificates?

Related:

• Move TLSv1.3 to sub-test and add TLSv1.3 to technical results #1643