DNSSec mess with SHA1
Petr Menšík
pemensik at redhat.com
Wed Jan 3 11:07:58 UTC 2024
Hello Wolfgang,
I would suggest using policy DEFAULT:SHA1 instead. It does not enable
all outdated algorithms, but enables only SHA1 in addition. Good choice
for dedicated DNS servers.
$ update-crypto-policies --set DEFAULT:SHA1
With my bind maintainer hat on, I need to clarify that it was ensured
SHA1 disabling does not cause fatal errors with default Red Hat provided
configuration. The magic happens in include provided by the system:
include "/etc/crypto-policies/back-ends/bind.config";
That ensures SHA1 algorithm is disabled, making SHA1 signed content just
unsigned, but otherwise resolvable. When you change policy to
DEFAULT:SHA1, it should make SHA1 enabled again automatically. Making it
secure again.
If you have custom named configuration, I would recommend to include
crypto-policies snippet in your options {} block. Unless you are
prepared to handle it manually of course.
The above should work for our RHEL9 supported versions (and derived
rebuilds) and also for ISC provided builds or your own builds. Newer
stable BIND releases have built-in autodetection of SHA1 support, which
makes it not necessary. But it is not error to include that anyway.
Best Regards,
Petr
On 12/15/23 13:21, Wolfgang Riedel via bind-users wrote:
> Hello,
>
> To answer my own question, the following will work:
>
> shadowman-200.png
> Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise
> Linux 8 | Red Hat Customer Portal
> <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening>
> access.redhat.com
> <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening>
>
> <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening>
>
>
> With:dnssec-validation auto;
>
>
> _Not working:_
> sudo update-crypto-policies —show
> DEFAULT
>
> _working:_
> update-crypto-policies --set LEGACY
>
> sudo update-crypto-policies --show
> LEGACY
>
> —
> Cheers,
> Wolfgang
> ______________________________________________________________________________________________
> Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559
>
>
>> On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users
>> <bind-users at lists.isc.org> wrote:
>>
>> Hello Petr,
>>
>> The issue is not just BIND local, as you can see on dnsviz.net
>> <http://dnsviz.net/>.
>> The whole chain of trust is broken.
>>
>> nist.gov <https://dnsviz.net/d/nist.gov/dnssec/>
>> dnsviz.net <https://dnsviz.net/d/nist.gov/dnssec/>
>> <logo_16x16.png> <https://dnsviz.net/d/nist.gov/dnssec/>
>>
>> <https://dnsviz.net/d/nist.gov/dnssec/>
>>
>> My question is more how you all deal with the fact on current and
>> updates systems???
>>
>>
>> Attached the requested information.
>>
>>
>> _1) Error Messages:_
>>
>> 15-Dec-2023 12:36:38.772 lame-servers: info: insecurity proof failed
>> resolving 'nist.gov/DNSKEY/IN': 2600:1480:800::43#53
>> 15-Dec-2023 12:36:39.302 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2600:1401:1::42#53
>> 15-Dec-2023 12:36:40.151 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2610:20:6b01:3::10#53
>> 15-Dec-2023 12:36:40.681 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2600:1401:2::d8#53
>> 15-Dec-2023 12:36:40.779 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2600:1480:9000::40#53
>> 15-Dec-2023 12:36:41.304 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2600:1406:32::43#53
>> 15-Dec-2023 12:36:41.321 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2600:1480:f000::41#53
>> 15-Dec-2023 12:36:41.784 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2610:20:6005:92::10#53
>> 15-Dec-2023 12:36:41.828 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 2.22.230.67#53
>> 15-Dec-2023 12:36:43.094 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 132.163.3.10#53
>> 15-Dec-2023 12:36:43.148 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 193.108.91.216#53
>> 15-Dec-2023 12:36:43.237 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 72.246.46.64#53
>> 15-Dec-2023 12:36:43.288 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 23.61.199.67#53
>> 15-Dec-2023 12:36:43.305 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 184.26.160.65#53
>> 15-Dec-2023 12:36:43.771 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 129.6.92.10#53
>> 15-Dec-2023 12:36:43.823 lame-servers: info: no valid RRSIG resolving
>> 'nist.gov/DNSKEY/IN': 23.211.133.66#53
>> 15-Dec-2023 12:36:43.824 lame-servers: info: broken trust chain
>> resolving 'www.nist.gov/A/IN': 2610:20:6005:92::10#53
>> 15-Dec-2023 12:36:45.905 lame-servers: info: broken trust chain
>> resolving 'www.nist.gov/A/IN': 2600:1480:f000::41#53
>> 15-Dec-2023 12:36:47.403 lame-servers: info: broken trust chain
>> resolving 'csrc.nist.gov/A/IN': 2600:1480:f000::41#53
>>
>> 15-Dec-2023 12:38:26.064 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3a::1#53
>> 15-Dec-2023 12:38:26.880 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3d::1#53
>> 15-Dec-2023 12:38:27.148 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.62.1#53
>> 15-Dec-2023 12:38:27.415 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.60.1#53
>> 15-Dec-2023 12:38:27.753 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.61.1#53
>> 15-Dec-2023 12:38:27.770 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.63.1#53
>> 15-Dec-2023 12:38:28.037 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3c::1#53
>> 15-Dec-2023 12:41:23.114 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3d::1#53
>> 15-Dec-2023 12:41:23.380 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3a::1#53
>> 15-Dec-2023 12:41:23.648 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.62.1#53
>> 15-Dec-2023 12:41:23.986 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.61.1#53
>> 15-Dec-2023 12:41:24.003 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.63.1#53
>> 15-Dec-2023 12:41:24.270 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 65.22.60.1#53
>> 15-Dec-2023 12:41:24.538 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3c::1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: no valid RRSIG resolving
>> 'apple/DNSKEY/IN': 2a01:8840:3b::1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: broken trust chain
>> resolving 'safebrowsing.apple/DS/IN': 2a01:8840:3d::1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: broken trust chain
>> resolving 'proxy.safebrowsing.apple/HTTPS/IN': 17.253.200.1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: broken trust chain
>> resolving 'token.safebrowsing.apple/HTTPS/IN': 17.253.200.1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: broken trust chain
>> resolving 'proxy.safebrowsing.apple/A/IN': 17.253.200.1#53
>> 15-Dec-2023 12:41:24.636 lame-servers: info: broken trust chain
>> resolving 'token.safebrowsing.apple/A/IN': 17.253.200.1#53
>>
>>
>> _2) Info about our Recursive Resolvers_
>>
>> Everything out of the box, native Rocky Linux 9 distribution
>> installation.
>>
>> cat /etc/*release
>> NAME="Rocky Linux"
>> VERSION="9.3 (Blue Onyx)"
>> ID="rocky"
>> ID_LIKE="rhel centos fedora"
>> VERSION_ID="9.3"
>> PLATFORM_ID="platform:el9"
>> PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
>> ANSI_COLOR="0;32"
>> LOGO="fedora-logo-icon"
>> CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
>> HOME_URL="https://rockylinux.org/"
>> BUG_REPORT_URL="https://bugs.rockylinux.org/"
>> SUPPORT_END="2032-05-31"
>> ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
>> ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
>> REDHAT_SUPPORT_PRODUCT="Rocky Linux"
>> REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
>> Rocky Linux release 9.3 (Blue Onyx)
>> Rocky Linux release 9.3 (Blue Onyx)
>> Rocky Linux release 9.3 (Blue Onyx)
>>
>> named -v
>> BIND 9.16.23-RH (Extended Support Version) <id:fde3b1f>
>>
>> openssl version
>> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)
>>
>> Out of the box /etc/ssl/openssl.cnf
>>
>> ls -lah /proc/sys/crypto/fips_enabled
>>
>>
>>
>> _3) More reading about the common issue:_
>>
>> 2073066 – (el9_dnssec_sha1) SHA-1 DNSSEC signatures are broken in
>> DEFAULT crypto-policy
>> <https://bugzilla.redhat.com/show_bug.cgi?id=2073066>
>> bugzilla.redhat.com <https://bugzilla.redhat.com/show_bug.cgi?id=2073066>
>>
>>
>> <https://bugzilla.redhat.com/show_bug.cgi?id=2073066>
>> It’s Time to Move Away From Using SHA-1 in the DNS
>> <https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en>
>> icann.org
>> <https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en>
>>
>>
>> <https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en>
>>
>> * SHA1 cryptographic hash algorithm was introduced in 1995 and is
>> now considered to be too weak to properly secure public web
>> sites. As such, it is being deprecated.
>> * Subsequent versions of Chrome will turn up the heat on SHA1 use.
>> * Windows will stop accepting SHA1 end-entity certificates by
>> January 1, 2017.
>> * Windows CAs should stop issuing new SHA1 SSL end-entity
>> certificates by January 1, 2016. The reason being that
>> certificates are valid for a minimum of 1 year. Since the
>> generally accepted date for deprecation is Jan 1, 2017, SHA1
>> certs should not be created after Jan 1, 2016, because the
>> expiration date of the certificate would be past the deprecation
>> date.
>> * See the Microsoft KB article for specifics on code signing
>> certificates.
>> * Microsoft is going to reevaluate their policy in July, 2015
>> * Mozilla has stated that they are in agreement with Microsoft and
>> Google and that SHA1 certificates should not be issued after Jan
>> 1, 2016 or trusted after Jan 1, 2017. They will phase in varying
>> degrees of messages moving forward. After Jan 1, 2017 Firefox
>> will show SHA1 protected sites as untrusted.
>>
>> —
>> Cheers,
>> Wolfgang
>> ______________________________________________________________________________________________
>> Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559
>>
>>> On 14. Dec 2023, at 09:09, Petr Špaček <pspacek at isc.org> wrote:
>>>
>>> On 14. 12. 23 8:58, Wolfgang Riedel via bind-users wrote:
>>>> Hi Folks,
>>>> I just wonder what's your take is on the current DNSSec mess with SHA1?
>>>> There are still a lot of top level domains being signed with SHA1
>>>> and look like nobody really cares?
>>>> Current OS releases like RHEL9 and others simply removed SHA1 from
>>>> the code so if you're running BIND with "dnssec-validation auto"
>>>> all those domains fails to resolve and the only way is to
>>>> "dnssec-validation no" which eliminated the whole idea of DNSSec!
>>>> The worst is that even nist.gov fails WFT!
>>>> https://dnsviz.net/d/nist.gov/dnssec/
>>>> Any advice or ideas?
>>>
>>> Given the lack of details it's hard to say. Widespread DNSSEC
>>> validation failures on RHEL 9 are not shared experience.
>>>
>>> Please provide:
>>> - **exact** version numbers
>>> - how you got the packages
>>> - which version of OpenSSL is in use, and how it's configured
>>> - Is FIPS mode is in play or not?
>>> ... and then we can get to diagnosing your issue.
>>>
>>> --
>>> Petr Špaček
>>> Internet Systems Consortium
>>> --
>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe from this list
>>>
>>> ISC funds the development of this software with paid support
>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>> information.
>>>
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>> <production.ico><favicon.ico>--
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/5fdc1463/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shadowman-200.png
Type: image/png
Size: 5828 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/5fdc1463/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9098 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/5fdc1463/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/5fdc1463/attachment-0001.sig>
More information about the bind-users
mailing list