Description of problem: Various crypto libraries in various crypto-policies modes place restrictions on allowed dhparam values. One example is OpenSSL in FIPS mode policy will only allow certain approved values. Another is LEGACY has a lower dhparam size than say, FUTURE. It'd be great to have well-known dhparams (e.g., from RFCs) packaged somewhere for other programs to utilize them, coupled with a well-known path to a default dhparam (perhaps /etc/crypto-policies/back-ends/dhparam.pem) suggested and allowed by the current policy and all engines which accept dhparam values. This would make maintaining packages across multiple crypto-policy modes more palatable. If not all dhparam values, then perhaps just one compatible with all available policies. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
In my opinion this does not make much sense as AFAIK the libraries are now shipping a set of well known DH parameter primes within their code and there is no need to set any DH parameters explicitly.
Although it is true that the libraries are moving in the right direction there is still a ton of software that requires parameters to be defined in configuration or generated in their startup scripts, so for those packages that still want it (whether right or wrong) this would help quite a bit to give packagers leverage and a good default to rely on.
But for these packages the right fix would be to not call the API to set the params explicitly. But I understand that just changing the configuration to point at some file shipped by some other package (not sure that crypto-policies would be the right package though) is much easier change. Also speaking about "ton of software" do we know any other concrete examples apart from the FreeRadius?
Postgres: - https://www.postgresql.org/docs/10/runtime-config-connection.html (ssl_dh_params_file) - Entire SSL section is commented out by default, ssl is off. - Doesn't appear to be Fedora patches to make it a no-op. nginx: - http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_dhparam - SSL enabled, ssl_dhparam not present in default config, popular option to add. - Doesn't appear to patch it to be a no-op. Apache httpd: - https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile - SSL enabled, doesn't appear to patch dhparam loading to be a no-op. MySQL apparently uses (used?) a hard-coded 512-bit value? https://bugs.mysql.com/bug.php?id=77602 But MariaDb appears to support loading dhparam values from tcert option? https://mariadb.com/kb/en/mariabackup-sst-method/ (Not sure if MySQL does as well) ^ Is the above built into OpenSSL as a single API call, and is dhparam loading from a cert bundle disabled? Mozilla recommends adding dhparam value, but suggests to use ffdhe2048: https://ssl-config.mozilla.org/ ...
I know I had to change the dh params for postifx and dovecot on my CentOS 8 box
Dovecot: - https://wiki.dovecot.org/SSL/DovecotConfiguration - generates new 1024/512 bit params on first start - expects user to set different ones in config file - Doesn't appear to be patched to change this behaviour Postfix: - http://www.postfix.org/FORWARD_SECRECY_README.html - ships compiled-in 2048 bit parameters since 3.1, that one is a random openssl-generated prime https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L82 - expects user to set different ones in config file - Doesn't appear to be patched to change this behaviour
That looks convincing. Still as all these depend on openssl it might be better to ship it in there. Or maybe even in a new separate subpackage of openssl that these applications could depend on so we do not pollute minimal installations.
Tomas, I think the suggestion was that crypto policy may change what file is used based on the policy, like DEFAULT could have all from 2048 and up, but Future would have a stricter set and so on. In that case having the files in crypto policy could be a decent idea, but I am ok also if you think it should be a an openssl subpackage and have named files in there or similar.
Question: Should this include all approved primes, or just the TLS primes. Our code now rejects all non-approved primes in FIPS mode, so that speaks to the former if the list is used for a generic DH operation, however the listed operations are all TLS operations, which should be restricted to the TLS primes (and not include the ike primes). TLS 1.3 itself has modes that require the TLS primes only (though those modes bypass the provided primes, and are builtin (AFAIK), which I think that's what Tomas is refering to.
OpenSSH (and libssh): In DH group exchange, malicious peer can send whatever prime matches the requested size (these days at least 2048b). The OpenSSH ships with /etc/ssh/moduli (updated on every upstream release). In FIPS, we patched this out to send and accept only standard MOTD groups: https://github.com/openssh/openssh-portable/blob/91a2135f32acdd6378476c5bae475a6e7811a6a2/dh.c#L341 https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-7.7p1-fips.patch#_110 If we would manage to get this working in some more standard and less patching way, it would be appreciated. Very similar code is in libssh, which is using the OpenSSH moduli file for dh-gex: https://git.libssh.org/projects/libssh.git/tree/src/dh-gex.c#n142
Not planned for next release, but I want this open as a reminder/tracker.