Runtime detection of SHA-1 support in unbound

[Paul Wouters]

Thanks, I will have a look.

Note you might also run into unbound startup issues as it tries to fetch the Icann pem bundle from icann.org which is also on rsasha1 - so ensure to check unbound’s PreStart items too.

https://stats.dnssec-tools.org/explore/?icann.org

Sent using a virtual keyboard on a phone

> On Apr 8, 2022, at 10:48, Petr Menšík <pemensik at redhat.com> wrote:
> 
> It seems I have successful prototype of unbound reacting to policy changes.
> 
> It seems it passes ietf.org or int as INSECURE if DEFAULT policy is
> active. But still passes it as secure if DEFAULT:SHA1 is active.
> 
> Tested just with unbound-host -rdD ietf.org
> 
> Create PR #660 [1], any testing, comments or review would be very welcome.
> 
> Cheers,
> Petr
> 
> 1. https://github.com/NLnetLabs/unbound/pull/660
> 
>> On 4/7/22 16:00, Paul Wouters wrote:
>> On Thu, 7 Apr 2022, Simo Sorce wrote:
>> 
>>>> It means RHEL9 cannot be used as a platform for DNS resolvers.
>>> 
>>> It can, you just need to set crypto-policies to allow SHA1 signatures.
>>> It is just a matter of configuration like many others.
>> 
>> but unbound has no seperate policies in the system-wide crypto
>> backends. Bind does, but will it be modified to allow SHA1? As I
>> understand it, it is the openssl backend that will refuse SHA1?
>> 
>>>> The unbound package should not use crypto-policies if those cannot
>>>> facilitate the requirements of RFC 8624.
>>> 
>>> This is applied at the openssl library level.
>> 
>> So that is a problem then. You have to enable it in openssl to make
>> it available to bind/unbound and now it is exposed to other parts too,
>> eg tls and ssh.
>> 
>>>> If Red Hat proceeds with this, users have two choices. Change the
>>>> system wide policy to LEGACY and degrading security for everything
>>>> running on the box (ssh, tls) or stick with rhel8 past its secure and
>>>> supported date.
>>> 
>>> We think this is a legitimate choice.
>>> But it does not need to be this drastic. A custom openssl configuration
>>> can be provided just to the application that needs to do DNSSEC
>>> verification via OPENSSL_CONF variable.
>>> 
>>> However we hope DNSSEC can move away from SHA1 quickly, there is no
>>> reason to stick to weak digest for so long.
>> 
>> Rubber meets the road somewhere and RFC 8624 has done these
>> determinations. If you think Red Hat can go against the worldwide
>> view/flow, then go ahead. You get to keep the pieces. The authors
>> of RFC 8624 are closely monitoring worldwide statistics and will
>> update the RFC when appropriate.
>> 
>> Note also that just breaking the crypto without proper support in the
>> DNS software causes ServFail's and not just a change from DNS data
>> being handles as "insecure" instead of "dnssec protected". This is
>> the bigger problem. Please do ensure unbound, bind et all do not
>> fail due to crypto library failing, but handle it properly as an
>> "unsupported algorithm" or otherwise there will be user outages.
>> 
>> Paul
>> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20220408/e931c274/attachment-0001.htm>