Deprecate DH harder

[mattcaswell]

This is very much an early sight WIP PR. It depends on #13136 and #13135 - those commits are included here.

Still to be done:

• There's still more of DH to deprecate, although I think I've solved most problem areas
• make update is doing some strange stuff. Needs investigation
• I had to deprecate some libssl functions/macros because they pass around a DH object. I need to implement EVP friendly replacements
• Better tests of dhparam

[t8m]

Do we actually need non-deprecated replacement for SSL_set_tmp_dh now that the libssl should automatically choose right safe prime from the known good ones? I propose to not add such replacement.

[mattcaswell]

Do we actually need non-deprecated replacement for SSL_set_tmp_dh now that the libssl should automatically choose right safe prime from the known good ones? I propose to not add such replacement.

I believe there are many people who want to use their specific DH params, and would be broken by removing that capability.

[t8m]

The reason they used specific DH params was mostly that the OpenSSL itself historically did not provide reasonable ones built in. But OK I suppose OpenSSL should still allow users to shoot themselves into their feet.

[slontis]

Do .pod files need updating also?

[mattcaswell]

Do .pod files need updating also?

Yes.

[slontis]

No problems.. I am mainly asking because I am doing the EC deprecation currently - just making sure that was not deliberate.

[mattcaswell]

I've rebased this to pick up #13136 and #13135 which have now been merged, so this PR is no longer dependent on them.

There's also been numerous updates, including deprecating the remaining DH functions and a number of fixes that resulted. Fixed the "make update" strangeness.

Still to do: documentation updates; more testing

[kroeckx]

So I'm confused what you think "no-dh" means. To me it means we have no support for DH at all, and that the EVP functions return an error in case you try to use them with DH.

[mattcaswell]

So I'm confused what you think "no-dh" means.

It means there is no low-level DH implementation. It so happens that if you have no DH implementation then the EVP functions will return an error. Unless you happen to plug in a third party provider that does have DH support, in which case it will start to work.

[kroeckx]

So that means that the SSL library always has DHE support, but just fails to negiotate a cipher using it? Or does it detect that DH is not provided, and then not announce it supports it/not select that as cipher?

[kroeckx]

This PR no longer support reading parameters from stdin, master still support this.

[t8m]

So that means that the SSL library always has DHE support, but just fails to negiotate a cipher using it? Or does it detect that DH is not provided, and then not announce it supports it/not select that as cipher?

It should be the latter - it should properly detect whether DH is provided or not and not announce/negotiate it if it isn't. Anything else would be a bug.

[mattcaswell]

So that means that the SSL library always has DHE support, but
just fails to negiotate a cipher using it? Or does it detect that
DH is not provided, and then not announce it supports it/not
select that as cipher?

Most algorithms (e.g. symmetric ciphers and hashes), it detects up front and does not offer ciphersuites based on that if there is no support. It also detects key exchange algorithms up front and does not offer groups in the supported_groups extension that it cannot support (including DH groups). However, checking the code, it looks to me like it doesn't actually suppress DH ciphersuites if it doesn't have DH support. It should do. I'll raise an issue for that.

[mattcaswell]

#13184

[mattcaswell]

This PR no longer support reading parameters from stdin, master still support this.

Hmm. I just tried this on master and got this output:

$ cat dh.pem | openssl dhparam -noout -text
Error, unable to load DH parameters
80C24B4C7A7F0000:error::STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:240:scheme=file
80C24B4C7A7F0000:error::DECODER routines:decoder_process:BIO lib:crypto/encode_decode/decoder_lib.c:511:

Trying the same thing on 1.1.1 works fine. So it looks to me like this is broken even in master.

[kroeckx]

The difference between this PR and master, is that on master it still waits for the data while this PR just directly returns an error.

[mattcaswell]

The difference between this PR and master, is that on master it
still waits for the data while this PR just directly returns an
error.

It still seems to fail at the same line in the OSSL_DECODER code though. I've raised an issue (#13185).

[mattcaswell]

Pushed. Thanks.