Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dist...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner == * Name: [[User:Asosedkin| Alexander Sosedkin]] * Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope == * Proposal owners: flip that switch in the DEFAULT policy, provide transitional policies for testing the change.
* Other developers: Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
* Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
* Policies and guidelines: CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
* Contingency mechanism: the change is reverted * Contingency deadline: Fedora 41 Beta Freeze * Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
Validating DNS resolvers are still required to be able to validate signatures made with SHA-1. RFC 8624 is still current as far as I can tell:
https://www.rfc-editor.org/rfc/rfc8624#section-3.1 https://www.rfc-editor.org/rfc/rfc8624#section-3.3
There have been reports of SHA-1 disablement causing name resolution problems. Here's one example:
https://lists.isc.org/pipermail/bind-users/2023-December/108182.html
Here's a crappy program that can show some statistics but won't let me link directly to the relevant table:
https://stats.dnssec-tools.org/
It shows about 140000 SHA-1-signed domains. That's only 6‰ of the signed domains, but still a rather large absolute number.
Before voting on this proposal, Fesco should be informed of what will happen in Bind, Unbound and SystemD-ResolveD when users try to look up a domain that is signed with SHA-1.
Will SHA-1 signatures be treated as invalid signatures, causing the resolver to return SERVFAIL? That will violate RFC 8624 and make users scramble for quick workarounds. Many will apply far too big hammers, such as disabling DNSsec validation entirely or switching their whole system to the LEGACY policy just to be able to resolve a domain name signed with SHA-1. In this case it should be announced far and wide how users can unbreak DNS without weakening the security of the rest of their system. Otherwise this change could easily do more harm than good.
Will DNSsec validation be skipped whenever an algorithm number for SHA-1 is encountered? That will make the resolver vulnerable to downgrade attacks. An attacker can then disable DNSsec by sending manipulated responses indicating for example RSA/SHA-1 for records that are actually signed with RSA/SHA-256.
If that were implemented relatively well, it might only introduce a vulnerability when a domain is signed both with SHA-1 and a stronger algorithm. If implemented badly, it could allow DNS cache poisoning to succeed even for domains signed only with strong algorithms. Here's a paper that discusses such vulnerabilities found in popular resolvers:
https://arxiv.org/pdf/2205.10608v1.pdf
It seems to me that the following would be the best way to distrust SHA-1 in DNSsec:
1: If a valid chain of trust can be established where strong algorithms are used throughout, then return the records to the client with the AD bit set, per the standard, indicating that the data are authentic.
2: If there should be signatures, but no valid chain of trust can be established because records are missing or signatures fail to verify, then assume it's an attack and return SERVFAIL per the standard.
3: If one or more valid chains of trust are found, but they all involve SHA-1 somewhere, then return the records to the client with the AD bit zeroed, indicating that no attack was detected but the data should not be trusted any more than an unsigned domain.
To be able to distinguish between cases 2 and 3, the resolver must remain able to verify SHA-1 signatures.
Björn Persson
Dear Björn,
On Sun, Jun 9, 2024 at 12:39 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
Validating DNS resolvers are still required to be able to validate signatures made with SHA-1. RFC 8624 is still current as far as I can tell:
https://www.rfc-editor.org/rfc/rfc8624#section-3.1 https://www.rfc-editor.org/rfc/rfc8624#section-3.3
There have been reports of SHA-1 disablement causing name resolution problems. Here's one example:
https://lists.isc.org/pipermail/bind-users/2023-December/108182.html
Here's a crappy program that can show some statistics but won't let me link directly to the relevant table:
https://stats.dnssec-tools.org/
It shows about 140000 SHA-1-signed domains. That's only 6‰ of the signed domains, but still a rather large absolute number.
I don't think that 140000 of something world-wide (22 mln of DNSSec signed domains) should be considered a large amount.
Before voting on this proposal, Fesco should be informed of what will happen in Bind, Unbound and SystemD-ResolveD when users try to look up a domain that is signed with SHA-1.
I agree that the maintainers of the DNSSec software have to consider the behavior of their software. But it doesn't mean that SHA1 for crypto purposes is of any security.
Will DNSsec validation be skipped whenever an algorithm number for SHA-1 is encountered? That will make the resolver vulnerable to downgrade attacks. An attacker can then disable DNSsec by sending manipulated responses indicating for example RSA/SHA-1 for records that are actually signed with RSA/SHA-256.
If an attacker can manipulate DNSSec so easily, it means it's completely broken.
It seems to me that the following would be the best way to distrust
SHA-1 in DNSsec:
1: If a valid chain of trust can be established where strong algorithms are used throughout, then return the records to the client with the AD bit set, per the standard, indicating that the data are authentic.
2: If there should be signatures, but no valid chain of trust can be established because records are missing or signatures fail to verify, then assume it's an attack and return SERVFAIL per the standard.
3: If one or more valid chains of trust are found, but they all involve SHA-1 somewhere, then return the records to the client with the AD bit zeroed, indicating that no attack was detected but the data should not be trusted any more than an unsigned domain.
To be able to distinguish between cases 2 and 3, the resolver must remain able to verify SHA-1 signatures.
Looks reasonable to me.
Hi Björn,
On 9. Jun 2024, at 00:37, Björn Persson Bjorn@xn--rombobjrn-67a.se wrote:
Validating DNS resolvers are still required to be able to validate signatures made with SHA-1. RFC 8624 is still current as far as I can tell:
https://www.rfc-editor.org/rfc/rfc8624#section-3.1 https://www.rfc-editor.org/rfc/rfc8624#section-3.3
That’s correct. There is some movement at the IETF, though. See [1] and thread. I’d also like to specifically point to [2], which I think sums up the discussion nicely. DNSSEC is a holdout, it feels like almost everybody else has moved by now to address the insecurity of SHA-1 in signatures. As you’ll also notice from the thread, there are a few voices that feel like we should not yet deprecate SHA-1 while it has not been completely broken.
There have been publications that say that DNSSEC is actually affected today if control over a zone is (even just partially) shared, see [3].
Personally, I don’t believe in waiting until the cat’s out of the bag if it will be in the foreseeable future. I’m quoting Leurent and Peyrin, who wrote the SHA-1 is a Shambles paper [4] in 2020: "Since our attack on SHA-1 has pratical [sic] implications, in order to make sure proper countermeasures have been pushed we will wait for some time before releasing source code that allows to generate SHA-1 chosen-prefix collisions.” [5] I believe hoping that Leurent and Peyrin will continue to sit on their code for another 5 years isn’t a good strategy (remember, the paper is from 2020(!)). I’m hoping the DNSSEC community will realize this soon.
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/gp7caSkWA9ureUStNuXtCpGmGss/ [2]: https://mailarchive.ietf.org/arch/msg/dnsop/XopFnthm0nFWrJ_z1tJYUoBwxrU/ [3]: https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/ [4]: https://eprint.iacr.org/2020/014.pdf [5]: https://sha-mbles.github.io/
There have been reports of SHA-1 disablement causing name resolution problems. Here's one example:
https://lists.isc.org/pipermail/bind-users/2023-December/108182.html
[…]
Before voting on this proposal, Fesco should be informed of what will happen in Bind, Unbound and SystemD-ResolveD when users try to look up a domain that is signed with SHA-1.
To my knowledge, DNS resolvers in RHEL and their upstreams have been adjusted to handle this, since RHEL 9 shipped with this configuration.
Are there DNS resolvers in Fedora that aren’t in RHEL?
Will SHA-1 signatures be treated as invalid signatures, causing the resolver to return SERVFAIL? That will violate RFC 8624 and make users scramble for quick workarounds. Many will apply far too big hammers, such as disabling DNSsec validation entirely or switching their whole system to the LEGACY policy just to be able to resolve a domain name signed with SHA-1. In this case it should be announced far and wide how users can unbreak DNS without weakening the security of the rest of their system. Otherwise this change could easily do more harm than good.
As far as I’m aware, the patches caused DNS resolvers to simply treat those zones as if they were unsigned.
It seems to me that the following would be the best way to distrust SHA-1 in DNSsec:
1: If a valid chain of trust can be established where strong algorithms are used throughout, then return the records to the client with the AD bit set, per the standard, indicating that the data are authentic.
2: If there should be signatures, but no valid chain of trust can be established because records are missing or signatures fail to verify, then assume it's an attack and return SERVFAIL per the standard.
3: If one or more valid chains of trust are found, but they all involve SHA-1 somewhere, then return the records to the client with the AD bit zeroed, indicating that no attack was detected but the data should not be trusted any more than an unsigned domain.
To be able to distinguish between cases 2 and 3, the resolver must remain able to verify SHA-1 signatures.
DNS resolvers can write code to do this. This proposal does not completely remove support for SHA-1 in signatures, it just disables it by default. Non-standard OpenSSL configurations can still verify SHA-1 signatures.
Hopefully the DNSSEC community will start discussions on what to do about post-quantum cryptographic signature algorithms soon, otherwise we’ll end up having the same discussion again in 10 years, when TLS and many other common protocols have moved.
On 08/06/2024 00:43, Aoife Moloney wrote:
OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
What about Git? AFAIK, AFAIK, Git heavily uses both SHA-1 and SHA-2 to validate objects and commits.
Vitaly Zaitsev via devel wrote on Sun, Jun 09, 2024 at 09:15:56AM +0200:
On 08/06/2024 00:43, Aoife Moloney wrote:
OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
What about Git? AFAIK, AFAIK, Git heavily uses both SHA-1 and SHA-2 to validate objects and commits.
git does not use OpenSSL to compute the hash, so nothing should change as far as I understand this
(..and from a quick look at recent release notes it'll be a while longer until we can see a transition, the support for sha256 commit ids has been implemented a while ago but "Work to support a repository that work with both SHA-1 and SHA-256 hash algorithms has stated" in git 2.45 (29 Apr 2024); right now a repo that wants to use sha256 needs to select that at git init time and pull/push won't work with something using sha1... and all forges like github refuse push if you try sha256. So some conversion path for existing repos and platforms support must come first, and there is none of that yet afaics, with work on the former that apparently just started)
Hi Vitaly,
On 9. Jun 2024, at 09:15, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/06/2024 00:43, Aoife Moloney wrote:
OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
What about Git? AFAIK, AFAIK, Git heavily uses both SHA-1 and SHA-2 to validate objects and commits.
Just to make sure: This proposed change does *not* disallow the use of SHA-1 for hashing (which is what git does).
It only prevents the use of SHA-1 for signing and signature verification. Git’s signature support [1] uses the OpenPGP packet format, which can (and in practice likely does) contain a different hash of the signed content, over which it creates a signature, so even commits with a SHA-1 commit ID can be signed in a fashion that will continue to validate with this change.
In https://fedoraproject.org/wiki/SHA1SignaturesGuidance:
At the moment, we don't provide a public API to enable SHA-1 signature support in OpenSSL programmatically. We ask you to respect the system administrator's configuration choice on this. We're planning to work with OpenSSL upstream to introduce a more suitable API in the future
Any news on this? Being able to make this policy configurable at application level would make things _much_ easier.
Zbyszek
On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
In https://fedoraproject.org/wiki/SHA1SignaturesGuidance:
At the moment, we don't provide a public API to enable SHA-1 signature support in OpenSSL programmatically. We ask you to respect the system administrator's configuration choice on this. We're planning to work with OpenSSL upstream to introduce a more suitable API in the future
Any news on this? Being able to make this policy configurable at application level would make things _much_ easier.
We don't plan to provide such an API, sorry. SHA1 is insecure. It should be eliminated from the crypto contexts _before_ a second-preimage attack starts to cost $0.02
On 6/9/24 11:27, Dmitry Belyavskiy wrote:
On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl mailto:zbyszek@in.waw.pl> wrote:
In https://fedoraproject.org/wiki/SHA1SignaturesGuidance <https://fedoraproject.org/wiki/SHA1SignaturesGuidance>: > At the moment, we don't provide a public API to enable SHA-1 signature > support in OpenSSL programmatically. We ask you to respect the system > administrator's configuration choice on this. We're planning to work > with OpenSSL upstream to introduce a more suitable API in the future Any news on this? Being able to make this policy configurable at application level would make things _much_ easier.We don't plan to provide such an API, sorry. SHA1 is insecure. It should be eliminated from the crypto contexts _before_ a second-preimage attack starts to cost $0.02
Is it the library's job to decide policies about security levels? Each time algorithms are "distrusted" people get problems mostly with things where security is not really critical at all, like connecting to their local hypervisor, their arduino boards, their home thermostat, etc. etc. etc. Let's hope at least the policies will be tweakable enough, I've seen cases where people were proposing removal of algorithms from the code, which is crazy (why should a library refuse to do an RC4 calculation for me?).
Regards.
Dear Roberto
On Sun, Jun 9, 2024 at 1:16 PM Roberto Ragusa mail@robertoragusa.it wrote:
On 6/9/24 11:27, Dmitry Belyavskiy wrote:
On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek <
zbyszek@in.waw.pl mailto:zbyszek@in.waw.pl> wrote:
In https://fedoraproject.org/wiki/SHA1SignaturesGuidance <https://fedoraproject.org/wiki/SHA1SignaturesGuidance%3E:
> At the moment, we don't provide a public API to enable SHA-1signature
> support in OpenSSL programmatically. We ask you to respect thesystem
> administrator's configuration choice on this. We're planning towork
> with OpenSSL upstream to introduce a more suitable API in thefuture
Any news on this? Being able to make this policy configurable atapplication
level would make things _much_ easier.We don't plan to provide such an API, sorry. SHA1 is insecure. It should
be eliminated from the crypto contexts _before_ a second-preimage attack starts to cost $0.02
Is it the library's job to decide policies about security levels? Each time algorithms are "distrusted" people get problems mostly with things where security is not really critical at all, like connecting to their local hypervisor, their arduino boards, their home thermostat, etc. etc. etc. Let's hope at least the policies will be tweakable enough, I've seen cases where people were proposing removal of algorithms from the code, which is crazy (why should a library refuse to do an RC4 calculation for me?).
You still are able to use SHA1 and RC4 using openssl.
The distribution should provide a necessary level of security defaults.Those who understand why they don't need enough security, can relax any limitations.
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
Vít
Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dist...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner ==
- Name: [[User:Asosedkin| Alexander Sosedkin]]
- Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope ==
- Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
- Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
- Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
- Policies and guidelines:
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
- Contingency mechanism: the change is reverted
- Contingency deadline: Fedora 41 Beta Freeze
- Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
Here's my 300-word attempt at it.
Hashing a piece of input data maps it to a fixed-size output (20 bytes in case of SHA-1). Cryptographic hash functions need to satisfy several more properties, and the one we're concerned with is collision resistance, i.e. computational infeasibility of finding another input hashing to the same value.
Signatures are a different thing altogether: a bit of data attached to a message attesting that the party is in possession of the private key. For technical reasons, it's not the input data that is signed, but the hash of it; this makes hashing the weak link in our situation. With the change landed, it's the openssl composite signature verification operation that will be disabled, not everything that says SHA-1 on the tin.
The kinds of scenarios that can conceivably break include: * an openssl wrapper library failing tests because the operation it exercises is now prohibited * some ill-designed protocol with no cryptographic agility (no way to switch to, say, RSA+SHA-2) will become unusable with no workaround other than allowing RSA-SHA1 back * your proprietary eye tracker drivers will fail to start or claim your license to use it is no longer valid or something * user pairing with an old unsupported iPad will see cryptic errors instead * other similarly exotic stuff which I don't even know exists and is hard to predict to fail without our detection tool or flipping the switch and seeing what breaks.
The kinds of scenarios that shouldn't be affected: * you verifying a Fedora 10 ISO download with sha1sum (integrity protection) * the website you hosting using SHA1() MariaDB function for password salting (though you should better switch to SHA2()) * your $sha1$40000$jtNX3nZ2$hBNaIXkt4wBI2o5rsi8KejSjNqIq entry in /etc/shadow on an old install * SHA-1 HMAC in TLS (integrity protection, doesn't need collision resistance) * other SHA-1 usage that has nothing to do with signatures
Hope that clarifies things.
---
Just an unrelated personal remark since I've got to the thread now:
Yes, I believe the scenarios above should be broken by default and require an explicit opt-in to work again. I'm not a fan of openssl failing to provide an API to re-enable it back per-process, but, on the other hand, gnutls went this extra mile and I haven't heard of it actually being used. I still consider a system-wide opt-back-in to be better than never switching. (or even a per-process-tree one, if you use runcp).
But no matter what I think of the situation though, Fedora is a community distro (that "always aims to provide the future, first") and if the Fedora community makes it clear once again that shipping secure defaults is not a desired property, I'll just relent and, likely, return with even more snark about all the "commitment to innovation" several releases later. Those unwilling to switch their crypto-policy for their proverbial eye tracker that they've already bought discontinued in 2016, and insisting that the said eye tracker now must now define the security baseline for millions of other Fedora installations: you have the means to stop me, it has been done once, and you can do it again.
On Mon, Jun 10, 2024 at 1:44 PM Vít Ondruch vondruch@redhat.com wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
Vít
Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dist...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner ==
- Name: [[User:Asosedkin| Alexander Sosedkin]]
- Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope ==
- Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
- Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
- Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
- Policies and guidelines:
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
- Contingency mechanism: the change is reverted
- Contingency deadline: Fedora 41 Beta Freeze
- Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
If you do not mind, I did a bit of touch-up to the opening paragraphs. A hashing function takes as input, a piece of input data, and maps it to a fixed-size output (20 bytes in case of SHA-1).
Cryptographic hash functions need to satisfy several more properties, and the one we are concerned with is "collision resistance". "Collision resistance" is a measure/value of computational infeasibility, such that the finding of another input, not necessarily of the same size as the original, and experiencing that the Cryptographic hash function creates a hashed output value containing same value as the original.
END OF TOUCHUP.
Signatures are a different thing altogether: a bit of data attached to a message attesting that the party is in possession of the private key. For technical reasons, it's not the input data that is signed, but the hash of it; this makes hashing the weak link in our situation. With the change landed, it's the openssl composite signature verification operation that will be disabled, not everything that says SHA-1 on the tin.
The kinds of scenarios that can conceivably break include: * an openssl wrapper library failing tests because the operation it exercises is now prohibited * some ill-designed protocol with no cryptographic agility (no way to switch to, say, RSA+SHA-2) will become unusable with no workaround other than allowing RSA-SHA1 back * your proprietary eye tracker drivers will fail to start or claim your license to use it is no longer valid or something * user pairing with an old unsupported iPad will see cryptic errors instead * other similarly exotic stuff which I don't even know exists and is hard to predict to fail without our detection tool or flipping the switch and seeing what breaks.
The kinds of scenarios that shouldn't be affected: * you verifying a Fedora 10 ISO download with sha1sum (integrity protection) * the website you hosting using SHA1() MariaDB function for password salting (though you should better switch to SHA2()) * your $sha1$40000$jtNX3nZ2$hBNaIXkt4wBI2o5rsi8KejSjNqIq entry in /etc/shadow on an old install * SHA-1 HMAC in TLS (integrity protection, doesn't need collision resistance) * other SHA-1 usage that has nothing to do with signatures
Hope that clarifies things.
---
Just an unrelated personal remark since I've got to the thread now:
Yes, I believe the scenarios above should be broken by default and require an explicit opt-in to work again. I'm not a fan of openssl failing to provide an API to re-enable it back per-process, but, on the other hand, gnutls went this extra mile and I haven't heard of it actually being used. I still consider a system-wide opt-back-in to be better than never switching. (or even a per-process-tree one, if you use runcp).
But no matter what I think of the situation though, Fedora is a community distro (that "always aims to provide the future, first") and if the Fedora community makes it clear once again that shipping secure defaults is not a desired property, I'll just relent and, likely, return with even more snark about all the "commitment to innovation" several releases later. Those unwilling to switch their crypto-policy for their proverbial eye tracker that they've already bought discontinued in 2016, and insisting that the said eye tracker now must now define the security baseline for millions of other Fedora installations: you have the means to stop me, it has been done once, and you can do it again.
On Mon, Jun 10, 2024 at 1:44 PM Vít Ondruch vondruch@redhat.com wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
Vít
Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):
Wiki - Changes/OpenSSLDistrustSHA1SigVer - Fedora Project Wiki Discussion Topic - F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner ==
- Name: [[User:Asosedkin| Alexander Sosedkin]]
- Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, SHA-1 is a Shambles claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope ==
- Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
- Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
- Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
- Policies and guidelines:
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
- Contingency mechanism: the change is reverted
- Contingency deadline: Fedora 41 Beta Freeze
- Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: Code of Conduct List Guidelines: Mailing list guidelines - Fedora Project Wiki List Archives: devel - Fedora Mailing-Lists Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
| | | | | |
|
| | | | Code of Conduct
Learn more about Fedora Linux, the Fedora Project & the Fedora Community. |
|
|
| | | | devel - Fedora Mailing-Lists
|
|
|
| | | | Mailing list guidelines - Fedora Project Wiki
|
|
|
| | | | SHA-1 is a Shambles
|
|
|
| | | | | |
|
| | | | F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (...
Make OpenSSL distrust SHA-1 signatures by default This is a proposed Change for Fedora Linux. This document rep... |
|
|
| | | | Changes/OpenSSLDistrustSHA1SigVer - Fedora Project Wiki
|
|
|
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
I'm annoyed that this is not just put behind the LEGACY policy, since if that's not what "legacy" is for, what _is_ it for?
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
Anyway, -1 from me.
Rich.
Vít
Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dist...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner ==
- Name: [[User:Asosedkin| Alexander Sosedkin]]
- Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope ==
- Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
- Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
- Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
- Policies and guidelines:
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
- Contingency mechanism: the change is reverted
- Contingency deadline: Fedora 41 Beta Freeze
- Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jun 10, 2024 at 8:16 PM Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
That's my general generic goal, yes, progressively more secure *defaults*. As long as crypto libraries don't drop legacy code, it should be enableable back through crypto-policies.
I'm annoyed that this is not just put behind the LEGACY policy,
Not only will it, obviously, still be enabled in LEGACY, (the proposal doesn't touch LEGACY at all), I'll also provide a subtler FEDORA40 policy for those less happy to downgrade their entire host's security. And custom policies also exist, of course. The choice is yours.
since if that's not what "legacy" is for, what _is_ it for?
No, LEGACY is for lagging behind the world / DEFAULT for a few years, not for unbounded backwards compatibility. But this is a different conversation we've been over countless times before.
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
Indeed. It's not trivial to implement a clean envvar-based dispatch or something, but there's a solution employing user namespaces that you can already try today: https://gitlab.com/redhat-crypto/crypto-policies-extras/-/blob/main/runcp.c https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras
Anyway, -1 from me.
Rich.
Vít
Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dist...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
== Owner ==
- Name: [[User:Asosedkin| Alexander Sosedkin]]
- Email: asosedki@redhat.com
== Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature.
With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means.
The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.
== Scope ==
- Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
- Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
- Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild.
- Policies and guidelines:
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default.
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
- Contingency mechanism: the change is reverted
- Contingency deadline: Fedora 41 Beta Freeze
- Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
On 10. Jun 2024, at 20:16, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
I'm annoyed that this is not just put behind the LEGACY policy, since if that's not what "legacy" is for, what _is_ it for?
I’m pretty sure Alex was planning to keep SHA-1 signatures working in the LEGACY policy, or even DEFAULT:SHA-1 (as it currently is on RHEL 9).
It isn’t explicitly spelled out in the proposal. What the proposal does say, though, is that you can use FEDORA40 as policy.
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
See this text in the proposal (emphasis mine):
Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (update-crypto-policies --set FEDORA40) or ***per-process (runcp FEDORA40 command args, requires a copr-packaged tool)***.
Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones rjones@redhat.com:
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
I'm annoyed that this is not just put behind the LEGACY policy, since if that's not what "legacy" is for, what _is_ it for?
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
Anyway, -1 from me.
Rich.
Anyway, -1 from me, too
For exactly that reason.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
Hi Peter,
On 11. Jun 2024, at 07:01, Peter Boy pboy@uni-bremen.de wrote:
Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones rjones@redhat.com:
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
I'm annoyed that this is not just put behind the LEGACY policy, since if that's not what "legacy" is for, what _is_ it for?
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
Anyway, -1 from me.
Rich.
Anyway, -1 from me, too
For exactly that reason.
Can you elaborate what you would need, in addition to the LEGACY policy (which still allows these connections) and the runcp utility?
Dear colleagues,
Let me try to summarize the pros and cons of this discussion.
Our intention is making the software and its settings as secure as possible by default. That's why we have crypto policies. The proposed change is aligned with the setting we have implemented in RHEL9 for 2-3 years, and there were only several use cases affected by this tightening, mostly SSH.
I understand that not all old systems are upgradeable (though many of them can be turned to smth using better algorithms - e.g. EC SSH keys are available on RHEL 7). So for these use cases we would like to propose either use runcp utility (which doesn't undermine the default settings) or, worst case, use a jump container. Any of this solution doesn't undermine the whole system's security.
I believe that now we could move this change forward, having a workaround for some use cases, probing to detect the legacy algorithm when it was missing, and higher security standards.
On Tue, Jun 11, 2024 at 12:02 PM Clemens Lang cllang@redhat.com wrote:
Hi Peter,
On 11. Jun 2024, at 07:01, Peter Boy pboy@uni-bremen.de wrote:
Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones rjones@redhat.com:
On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote:
I wish this proposal included some examples of what might get broken and what will keep working. I guess I am not the only one who have very vague understanding what is difference between "signatures" and "hashing" or other purposes SHA1 can be used for.
SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and to old network equipment and the like will not be possible.
I'm annoyed that this is not just put behind the LEGACY policy, since if that's not what "legacy" is for, what _is_ it for?
As an aside, it'd be very nice if policies could be set per-process. That would greatly enhance security by allowing specific programs to connect to the legacy machines, while maintaining general system security.
Anyway, -1 from me.
Rich.
Anyway, -1 from me, too
For exactly that reason.
Can you elaborate what you would need, in addition to the LEGACY policy (which still allows these connections) and the runcp utility?
-- Clemens Lang RHEL Crypto Team Red Hat
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Am 11.06.24 um 16:09 schrieb Dmitry Belyavskiy:
Dear colleagues,
Let me try to summarize the pros and cons of this discussion.
Our intention is making the software and its settings as secure as possible by default. That's why we have crypto policies. The proposed change is aligned with the setting we have implemented in RHEL9 for 2-3 years, and there were only several use cases affected by this tightening, mostly SSH.
I understand that not all old systems are upgradeable (though many of them can be turned to smth using better algorithms - e.g. EC SSH keys are available on RHEL 7). So for these use cases we would like to propose either use runcp utility (which doesn't undermine the default settings) or, worst case, use a jump container. Any of this solution doesn't undermine the whole system's security.
toolbox is a nice helper for such cases ...
I believe that now we could move this change forward, having a workaround for some use cases, probing to detect the legacy algorithm when it was missing, and higher security standards.
V Tue, Jun 11, 2024 at 04:09:54PM +0200, Dmitry Belyavskiy napsal(a):
I understand that not all old systems are upgradeable (though many of them can be turned to smth using better algorithms - e.g. EC SSH keys are available on RHEL 7). So for these use cases we would like to propose either use runcp utility
Is the runcp utility packaged for Feodora?
-- Petr
-
Alexander Sosedkin -
Aoife Moloney -
Björn Persson -
Clemens Lang -
Dmitry Belyavskiy -
Dominique Martinet -
Leon Fauster -
Leslie Satenstein -
Peter Boy -
Petr Pisar -
Richard W.M. Jones -
Roberto Ragusa -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek