< Changes
(Draft an initial version of OpenSSLDistrustSHA1SigVer) |
(Remove the draft warning from the top of the page) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
| Line 8: | Line 6: | ||
== Summary == | == Summary == | ||
OpenSSL will no longer trust cryptographic signatures using SHA-1 by default starting from Fedora 41. | OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41. | ||
== Owner == | == Owner == | ||
| Line 42: | Line 40: | ||
== Detailed Description == | == 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. | 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 | With this change accepted and implemented, | ||
OpenSSL will start blocking SHA-1 signature creation and verification by default. | OpenSSL will start blocking SHA-1 signature creation and verification by default. | ||
| Line 52: | Line 50: | ||
== Feedback == | == Feedback == | ||
This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] | This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], | ||
has proved itself controversial. | has proved itself controversial. | ||
There seems to be a consensus that the change has to be done | There seems to be a consensus that the change has to be done sooner or later, | ||
but Fedora is a remarkably conservative distribution | but Fedora is a remarkably conservative distribution | ||
when it comes to deprecating legacy cryptography, even if by-default-only. | when it comes to deprecating legacy cryptography, even if by-default-only. | ||
| Line 61: | Line 59: | ||
The decision to discover code reliant on SHA-1 signatures | The decision to discover code reliant on SHA-1 signatures | ||
by blocking creation/verification has not gathered many fans, | by blocking creation/verification has not gathered many fans, | ||
but not many alternative proposals have been raised in return. | 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. | 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 | Opt-in logging through USDT probes has been implemented the last time | ||
and can be reinstated if need be. | and can be [https://gitlab.com/fedora/src/openssl/-/merge_requests/3 reinstated] to test this feature if need be. | ||
The precursor change has received limited testing during Fedora 37 Test Days, | The precursor change has received limited testing during Fedora 37 Test Days, | ||
with only a handful of bugs discovered. | 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, | The change has received significant testing in RHEL, | ||
which distrusts SHA-1 signatures by default starting from RHEL-9. | 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 == | == Benefit to Fedora == | ||
| Line 82: | Line 82: | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
Test your applications | Test your applications under TEST-FEDORA41 policy. | ||
If the security of your application depends on trusting SHA-1 | If the security of your application depends on trusting SHA-1 signatures, | ||
fix this, or it stop working unless users explicitly opt into lower security guarantees. See | fix this, or it will stop working unless users explicitly opt into lower security guarantees. See | ||
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. | [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/12096 #12096] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
| Line 112: | Line 112: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
The change is not expected to break upgrades. | 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 | Administrators willing to retain previous behavior and sacrifice security | ||
will be able to apply a compatibility policy or subpolicy | |||
before or after the upgrade. | before or after the upgrade. | ||
| Line 145: | Line 147: | ||
and the policies under which your workflow does and does not work. | and the policies under which your workflow does and does not work. | ||
Alternatively, a tool to identify the affected operation without blocking them | 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. | |||
It first needs [https://gitlab.com/fedora/src/openssl/-/merge_requests/3 the following patch] to openssl though. | |||
== User Experience == | == User Experience == | ||
| Line 162: | Line 165: | ||
Some less-than-common use-cases will break. | Some less-than-common use-cases will break. | ||
(One example from Fedora 37 test days was interoperability with old Apple devices). | (One example from Fedora 37 test days was interoperability with old Apple devices). | ||
The affected users will need to either explicitly opt into | 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. | 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 == | == Dependencies == | ||
Latest revision as of 17:16, 9 May 2024
Make OpenSSL distrust SHA-1 signatures by default
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: Alexander Sosedkin
- Email: asosedki@redhat.com
Current status
- Targeted release: Fedora Linux 41
- Last updated: 2024-05-09
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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 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 , 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 can be reinstated to test this feature if need be.
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.
- Release engineering: #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. It first needs the following patch to openssl though.
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 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 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.