Different results with sslyze 6.1.0

[friedelwolff]

Firstly, thanks for sslyze!

When testing my domains against Mozilla's intermediate configuration, I get a failure when upgrading to version 6.1.0. sslyze 6.0.0 and ssllabs.com are still happy with my configuration.

Steps to reproduce the behaviour:

1. Install SSLyze using pip
2. Run sslyze --mozilla_config intermediate sadilar.org
3. See output:

    sadilar.org:443: FAILED - Not compliant.
        * tls_curves: TLS curves {'secp256k1', 'secp521r1'} are supported, but should be rejected.
        * tls_vulnerability_extended_master_secret: Server does not support the Extended Master Secret TLS extension.

Expected behaviour
With sslyze 6.0.0 for the same host passes successfully:

    sadilar.org:443: OK - Compliant.

Python environment:

• My local Mageia OS with Python 3.10
• also on our CI system which is using the docker image python:3.11-slim (Debian based)

Additional related issue:
On a different host (mvn.sadilar.org) which has a different web server (but also the Mozilla intermediate configuration), gives different output, but this is also new with sslyze 6.1.0:

mvn.sadilar.org:443: FAILED - Not compliant.

        * certificate_curves: Certificate curve is secp256r1, should be one of {'secp384r1', 'prime256v1'}.
        * tls_curves: TLS curves {'secp521r1', 'X448'} are supported, but should be rejected.

[nabla-c0d3]

Hello,

The Mozilla intermediate profile requires specific curves to be enabled (https://github.com/nabla-c0d3/sslyze/blob/release/sslyze/mozilla_tls_profile/5.7.json#L90). This requirement was previously disabled (in SSLyze v6.0.0) and has been enabled in v6.1.0.

The check for Extended Master Secret TLS extension is a new check; see also https://www.redhat.com/en/blog/tls-extended-master-secret-and-fips-rhel

[friedelwolff]

Thank you for your response. I'm not very familiar with the subject matter. Since my web server configuration is basically the configuration provided by Mozilla (https://ssl-config.mozilla.org) I was surprised that it isn't sufficient.

From a little bit of reading, EMS addresses an exploit on RSA or Diffie-Hellman key exchange, and my servers uses elliptic curve key exchange. Is the EMS check meaningful in this case?

I'm still investigating why my copy of the Mozilla provided configuration isn't sufficient for the curves.

[friedelwolff]

Regarding the curves, I have additional information that I believe can help.

When sslyze 6.1.0 outputs the following:
certificate_curves: Certificate curve is secp256r1, should be one of {'prime256v1', 'secp384r1'}.
it seems to ignore the fact that secp256r1 and prime256v1 are different names for the same curve. See Appendix A in RFC 8422. I assume the names are coming from libraries, and that the vocabulary of names are not consistent. From that appendix A, I assume normalising all names to the SEC names would help to alleviate this issue.

Confusingly, the output of sslyze sadilar.org (with sslyze 6.1.0) includes
Supported curves: prime256v1
but then complains later down that it should be one of {'prime256v1', 'secp384r1'} - which it is.

I hope that helps.