Created attachment 2005355 [details] unbound log with verbosity 4 Package version: unbound-1.19.0-1.fc39.x86_64 Change crypto policy to FUTURE removing sha1 from supported encryption algoritms. update-crypto-policies --set FUTURE Now verification of RSASHA1 signatures causes insecure responses like expected. But current code doesn't handle RSASHA1-NSEC3-SHA1, so for example command: dig nvd.nist.gov aaaa Query fails with NXDOMAIN. Expected response would be insecure one, not verification failure. Same error can be produced on CentOS Stream 9 by building unbound-1.19.0 with sha1 enabled (centos/rhel package build with --disable-sha1).
Indeed. Tested on Fedora Rawhide. With default policy it works nice: # unbound-host -rvD nvd.nist.gov nvd.nist.gov is an alias for nvd.glb.nist.gov. (secure) nvd.glb.nist.gov has address 54.85.30.225 (secure) nvd.glb.nist.gov has IPv6 address 2600:1f18:268d:1d01:f609:5e91:8a48:f546 (secure) nvd.glb.nist.gov has no mail handler record (secure) But after changing to FUTURE, it starts failing. # unbound-host -rvD nvd.nist.gov nvd.nist.gov is an alias for nvd.glb.nist.gov. (BOGUS (security failure)) nvd.glb.nist.gov has address 54.85.30.225 (BOGUS (security failure)) validation failure <nvd.nist.gov. A IN>: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 10.2.70.215 for key nist.gov. while building chain of trust nvd.glb.nist.gov has IPv6 address 2600:1f18:268d:1d01:f609:5e91:8a48:f546 (BOGUS (security failure)) validation failure <nvd.nist.gov. AAAA IN>: key for validation nist.gov. is marked as invalid because of a previous no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 nvd.glb.nist.gov has no mail handler record (BOGUS (security failure)) validation failure <nvd.nist.gov. MX IN>: key for validation nist.gov. is marked as invalid because of a previous no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 # unbound-host -rvD nist.gov -t DNSKEY nist.gov has DNSKEY record 256 3 7 AwEAAcUoQZuzU98xu6uC4L7WBehqKF480X6zTaeDYmju8tWBYk9kZHE3+Wvy98TieCWCmhUJ18PjPWQI06N8BDa50zj1sY0A8D1ZSHjzO2XKmdsDu+h5fCWELKUHxiKLQrjrch1paWPSBDHVHhpXHnmGt2fUi53mtVipgsKmEVbBG79V (BOGUS (security failure)) nist.gov has DNSKEY record 256 3 7 AwEAAcgw0dLYv0aU45GIGobpM8xKVUhj/UV0rzeBLmIIyD7lDQqC7uAh6lf0z8MM0xlgR/MG0XNlBDbc2ytETLMRuB3ja0VDjNmtTvRuOoHAcZzDeGF6avDsQuRDUMYgxD0M2O6kDr6oAYJCFF5K39HAVJi7y8ena1FCvEYaY5J9USN9 (BOGUS (security failure)) nist.gov has DNSKEY record 257 3 7 AwEAAZsKqv2KvXxDVSE1GV6Mve+H00TKcmKRA1J6Z8vDksegaYT2i1AwCsYZZ3N+QGoTxcOpKPFwNj7AgsXiJ5r5TyA4sMpDmDn7V6OobOfjtOZtvLuZwJNQrCxqJHektDS/FOxIjLpkjb0roJsnyf/lfpqmbGBOGt2qtAVAJ9sEPtsSM9iwth7gqnKnDvtBE81jm1aBpvlnBbHxr+5D+S41Y+sWywiDZgXYNJIhGLCWYX4o664U8y1yARxtS/QD3cVEpCtGC5xdHrfV3zEO9rDvhLMZBjDlRQk0czyQ3shv01dRR90RxKXP8x7F6nqjHnxVvd6/w5SiFUA+SZCO5DYtreU= (BOGUS (security failure)) validation failure <nist.gov. DNSKEY IN>: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 10.11.5.160 for key nist.gov. while building chain of trust # unbound-host -rvD nist.gov -t DS nist.gov has DS record 35565 7 2 A051B24A47293959EEE0D5E21D74D2BD60B814DF03237DFD60FFDD1DD6AA25AE (secure) nist.gov has DS record 57228 7 2 27782FD40AA9408FFB98D93C4C095BBD652459CBD3FC2F58549A7399E4789A61 (secure) nist.gov has DS record 35565 7 1 DB68A6356C64A8CC24357D3FE42E1B4194A96245 (secure) This is why we have disabled SHA1 on RHEL/CentOS 9, where disabled SHA1 is a default. I admit we lack any test ensuring also different crypto policies have working SHA1 verification. # update-crypto-policies --set DEFAULT:SHA1 Setting system policy to DEFAULT:SHA1 Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. # unbound-host -rvD nist.gov -t DNSKEY nist.gov has DNSKEY record 257 3 7 AwEAAZsKqv2KvXxDVSE1GV6Mve+H00TKcmKRA1J6Z8vDksegaYT2i1AwCsYZZ3N+QGoTxcOpKPFwNj7AgsXiJ5r5TyA4sMpDmDn7V6OobOfjtOZtvLuZwJNQrCxqJHektDS/FOxIjLpkjb0roJsnyf/lfpqmbGBOGt2qtAVAJ9sEPtsSM9iwth7gqnKnDvtBE81jm1aBpvlnBbHxr+5D+S41Y+sWywiDZgXYNJIhGLCWYX4o664U8y1yARxtS/QD3cVEpCtGC5xdHrfV3zEO9rDvhLMZBjDlRQk0czyQ3shv01dRR90RxKXP8x7F6nqjHnxVvd6/w5SiFUA+SZCO5DYtreU= (secure) nist.gov has DNSKEY record 256 3 7 AwEAAcUoQZuzU98xu6uC4L7WBehqKF480X6zTaeDYmju8tWBYk9kZHE3+Wvy98TieCWCmhUJ18PjPWQI06N8BDa50zj1sY0A8D1ZSHjzO2XKmdsDu+h5fCWELKUHxiKLQrjrch1paWPSBDHVHhpXHnmGt2fUi53mtVipgsKmEVbBG79V (secure) nist.gov has DNSKEY record 256 3 7 AwEAAcgw0dLYv0aU45GIGobpM8xKVUhj/UV0rzeBLmIIyD7lDQqC7uAh6lf0z8MM0xlgR/MG0XNlBDbc2ytETLMRuB3ja0VDjNmtTvRuOoHAcZzDeGF6avDsQuRDUMYgxD0M2O6kDr6oAYJCFF5K39HAVJi7y8ena1FCvEYaY5J9USN9 (secure) # update-crypto-policies --set DEFAULT:NO-SHA1 Setting system policy to DEFAULT:NO-SHA1 Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. # unbound-host -rvD nist.gov -t DNSKEY nist.gov has DNSKEY record 257 3 7 AwEAAZsKqv2KvXxDVSE1GV6Mve+H00TKcmKRA1J6Z8vDksegaYT2i1AwCsYZZ3N+QGoTxcOpKPFwNj7AgsXiJ5r5TyA4sMpDmDn7V6OobOfjtOZtvLuZwJNQrCxqJHektDS/FOxIjLpkjb0roJsnyf/lfpqmbGBOGt2qtAVAJ9sEPtsSM9iwth7gqnKnDvtBE81jm1aBpvlnBbHxr+5D+S41Y+sWywiDZgXYNJIhGLCWYX4o664U8y1yARxtS/QD3cVEpCtGC5xdHrfV3zEO9rDvhLMZBjDlRQk0czyQ3shv01dRR90RxKXP8x7F6nqjHnxVvd6/w5SiFUA+SZCO5DYtreU= (BOGUS (security failure)) nist.gov has DNSKEY record 256 3 7 AwEAAcUoQZuzU98xu6uC4L7WBehqKF480X6zTaeDYmju8tWBYk9kZHE3+Wvy98TieCWCmhUJ18PjPWQI06N8BDa50zj1sY0A8D1ZSHjzO2XKmdsDu+h5fCWELKUHxiKLQrjrch1paWPSBDHVHhpXHnmGt2fUi53mtVipgsKmEVbBG79V (BOGUS (security failure)) nist.gov has DNSKEY record 256 3 7 AwEAAcgw0dLYv0aU45GIGobpM8xKVUhj/UV0rzeBLmIIyD7lDQqC7uAh6lf0z8MM0xlgR/MG0XNlBDbc2ytETLMRuB3ja0VDjNmtTvRuOoHAcZzDeGF6avDsQuRDUMYgxD0M2O6kDr6oAYJCFF5K39HAVJi7y8ena1FCvEYaY5J9USN9 (BOGUS (security failure)) validation failure <nist.gov. DNSKEY IN>: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 10.11.5.160 for key nist.gov. while building chain of trust
See upstream bug report, and complete analysis there.
This happens to be default since f41 branch. It needs similar disabling of SHA1 like RHEL9+ has.
This exacat case works just fine without disabling sha1 in build time. But I found another similar issue where crypto-policy blocking sha1 causes failure. Note: rfc still requires dns resolver to verify sha1 signatures. So it is not ok to disable sha1 at resolver build time.
I ment: This exact case is fixed in latest unbound.
Yes, I know. It uses the same fix as RHEL9. Disadvantage of this approach is it does not validate when update-crypto-policies --set DEFAULT:SHA1. Which is not ideal, but it is the fastest fix of bug #2301344. It disables algorithm 5 and 7 in all crypto policies in all cases.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
It seems latest unbound can pass when only tests are made to use SHA1. That can be done by simple 3 line openssl configuration. cat > sha1-ok.conf << EOF .include = /etc/ssl/openssl.cnf [evp_properties] rh-allow-sha1-signatures = yes EOF export OPENSSL_CONF="$PWD/sha1-ok.conf" make check This fixes problem with test, therefore build-time disabling of SHA1 can be removed.
This is now very actual for Fedora 41, where disabling of SHA1 happens on DEFAULT crypto policy. But I have found a way to get around this limitation. Above solution fixes passing tests. Will add simpler way to enable SHA1 validation.
FEDORA-2024-8bb71c1fd7 (unbound-1.22.0-7.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-8bb71c1fd7
FEDORA-2024-aecc7c321e (unbound-1.22.0-7.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-aecc7c321e
FEDORA-2024-aecc7c321e has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-aecc7c321e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-aecc7c321e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-deb9b3f394 (unbound-1.22.0-8.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-deb9b3f394
FEDORA-2024-deb9b3f394 (unbound-1.22.0-8.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-aecc7c321e (unbound-1.22.0-8.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.