On 18. 11. 24 15:37, Paul Wouters wrote:
On Sun, 17 Nov 2024, Philip Homburg wrote:
[indeed a bit offtopic]
Correct, it is now compiled using --disable-sha1. I think it would be
better to enable this again, assuming unbound now has proper code to
detect if sha1 is failing or not during runtime.
On Sun, 17 Nov 2024, Philip Homburg wrote:
[indeed a bit offtopic]
Use OPENSSL_CONF environment to point to conf file containing:
.include = /etc/ssl/openssl.cnf
[evp_properties]
rh-allow-sha1-signatures = yes
That is all needed to get SHA1 verification in DNSSEC back, without
accepting SHA1
Yes, I know it does not help now. In fact what blocked me on enabling it
in the build were not passing unit tests and other tests after the
build. I solved them by using this recipe at Fedora [1]. I will try to
enable it in new minor RHEL versions, but already published releases
will probably s
>I have found there is no need to link to different library. What is
>needed is just different *configuration*. I found a very simple method
>to share with you:
>
>Use OPENSSL_CONF environment to point to conf file containing:
>
>.include = /etc/ssl/openssl.cnf
>[evp_properties]
>rh-allow-sha1-sign
I have found there is no need to link to different library. What is
needed is just different *configuration*. I found a very simple method
to share with you:
Use OPENSSL_CONF environment to point to conf file containing:
.include = /etc/ssl/openssl.cnf
[evp_properties]
rh-allow-sha1-signatures
On 11/13/24 19:55, Philip Homburg wrote:
See our I-D on lifecycle. It addresses this issue squarely.
The problem is that RedHat went ahead and disabled support for SHASHA1
(in the default configuration). That results in systems that
violate the current DNSSEC standards.
Yes. Given that
It was the red hat situation that led me to write this. Red hat should have
gone to phase 6, not phase 7.
I recommend moving SHASHA1 to phase 6 for the time being.
Steve
Sent from my iPhone
> On Nov 13, 2024, at 7:55 PM, Philip Homburg
> wrote:
>
>
>>
>> See our I-D on lifecycle. It
>See our I-D on lifecycle. It addresses this issue squarely.
The problem is that RedHat went ahead and disabled support for SHASHA1
(in the default configuration). That results in systems that
violate the current DNSSEC standards. It seems some people would like to
change the standards in suc
See our I-D on lifecycle. It addresses this issue squarely. I'm about to
to dinner and can't fill in the details. I'll do so later if someone
hasn't already.
Steve
Sent by a Verified
sender
On Wed, Nov 13, 2024 at 7:04 PM Philip Homburg
wrote:
> >Tony Finch has correctly identified in SHA
>Tony Finch has correctly identified in SHA-1 chosen prefix collisions
>and DNSSEC [3] article that when a single record is usually safe,
>multiple records might allow creating fake signature even in DNSSEC.
There are two types of attacks on hash functions: collisions and second
pre-image attac
Hello Paul,
I am aware Red Hat is not loved for the way, how the disabling of
RSASHA1 algorithm were handled in our products, especially Red Hat
Enterprise Linux 9.
While primary target of our crypto people were disallowing SHA-1 usage
in TLS channels and signatures of documents, I think the
11 matches
Mail list logo
