Diffie Helmann information for each cipher suite no longer returned

[BenjaminHae]

In version 2.0.0 the dh_info key for ciphers that use Diffie-Hellmann key exchange has disappeared.
Are you planning to bring it back, or is it gone for good?

Example JSON from 1.4.3:

    "tlsv1": {
                    "accepted_cipher_list": [
                        {
                            "dh_info": {
                                "A": "0x00ffffffff00000001000000000000000000000000fffffffffffffffffffffffc",
                                "B": "0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b",
                                "Cofactor": "1",
                                "Field_Type": "prime-field",
                                "Generator": "0x046b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c2964fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5",
                                "GeneratorType": "uncompressed",
                                "GroupSize": "256",
                                "Order": "0x00ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551",
                                "Prime": "0x00ffffffff00000001000000000000000000000000ffffffffffffffffffffffff",
                                "Seed": "0xc49d360886e704936a6678e1139d26b7819f7e90",
                                "Type": "ECDH"
                            },
                            "is_anonymous": false,
                            "key_size": 256,
                            "openssl_name": "ECDHE-RSA-AES256-SHA",
                            "ssl_version": "TLSV1"
                        },

Example from 2.0.0:

                        {
                            "is_anonymous": false,
                            "key_size": 256,
                            "openssl_name": "ECDHE-RSA-AES256-SHA",
                            "ssl_version": "TLSV1_1"
                        },

[nabla-c0d3]

I want to bring it back but the previous code was too difficult to maintain.

[faldridge]

I need this as well. Was the problem with both the C code and the Python usage of it?

I ask because I'm interested in submitting a PR and was wondering if simply restoring the low-level Python extensions, and then using them in the new Python SSL client code would be a valid approach.

[nabla-c0d3]

The problem was that the code that was reading the DH information was using "private" APIs and data structures; hence it would only work on specific versions of OpenSSL, and it also required some heavy lifting to be done during the build process.
When I had to add OpenSSL 1.1.1 (for TLS 1.3 support) in the new version of SSLyze, the DH code did not work with that version of OpenSSL. Then I decided to remove the DH code.

The right way to bring the functionality back would be to find an "official"/public API to retrieve the DH info in OpenSSL 1.1.1.

[faldridge]

Thanks for the update! I'll try to work on this as I have time.

[SQ-SEN]

A fix for this would be really appreciated. Currently I have to run all tests twice - with 1.4.1 and 2.0.1. A lot of setups have issues with DH param strength...

[ninijay]

Bump, because I would really appreciate this fix

[ninijay]

Also, the 1.1.1 manpages have some info about DH:

• https://www.openssl.org/docs/man1.1.1/man3/DH_check_params.html
• https://www.openssl.org/docs/man1.1.1/man3/DH_check.html

I'm not sure what endpoint you'll need for sslyze, but maybe you can find something useful in these search results.

[botastic]

I'd also really appreciate some more information on the key exchange and the authentication used.

[botastic]

Correct me if I'm wrong:
According to the RFC, the server must provide a certificate that is meeting the requierments of the negotiated cipher suite. Therefore the server has to have different certificates if multiple cipher suites with different key exchange algorithms are supported. SSLyze only returns one certificate chain.

If we'd check the certificate for every accepted cipher suite, then we can get the public key and information about the key exchange (and authentication) from the certificate and don't depend on OpenSSL.

This would of course come with the overhead of requesting a lot more certificate chains, but this also seems to be the "correct" implementation to me.

I think we would need to create a new plugin as the certificate and cipher suite plugins are currently indepent, but I just had a quick look.

[BenjaminHae]

@botastic a server usually only supports one authentication algorithm- In most cases this is RSA, in some cases it is ECDSA (or much rarer DSS).
Ciphers starting with TLS_DHE_RSA_WITH_ use the DHE key exchange but RSA as authentication. So even if DHE is used for key exchange, the certificate will contain an RSA public key.
I don't remember ever seeing a server supporting ciphers matching TLS_*_RSA_WITH_* and TLS_*_ECDSA_WITH_* at the same time (though it is definiteley possible: https://hackernoon.com/rsa-and-ecdsa-hybrid-nginx-setup-with-letsencrypt-certificates-ee422695d7d3). Only in that case 2 certificates are needed.
In most cases only one certificate is necessary and possible as either ECDSA or RSA are supported by the server as authentication mechanism.

If you have such a server I am really interested in seeing the results of sslyze.

[botastic]

Unfortunately I don't, but it really would be interesting.

Nonetheless, wouldn't it still be better to check all certificates or supply an option for it? If different certificates are allowed for different cipher suites with the same authentication method, one of them could have a weak RSA (/ECDSA/DSS) key while the other ones have perfectly fine ones. Admittedly this is rather unlikely.

[BenjaminHae]

@botastic I just had someone look into it: If there are two certificates (ECDSA and RSA), only one of them is shown in the results (console or JSON output). Testssl however shows both certificates.

[r0oth3x49]

we can still calculate DH information from Handshake bytes

[nabla-c0d3]

@FWinterborn opened some really cool pull requests for this:

• Add function to extract DH/ECDH from connection nassl#48
• Added DH/ECDH info to output #394

I ll try to get them released soon.

[fabian-hk]

I am really interested in the changes @FWinterborn made because I need them for my Bachelor Thesis project. Is there a timetable when this is going to be released? And is there something I can help you with?

[nabla-c0d3]

Fixed in v3.0.0.