F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-distrust-sha-1-signatures-by-default-system-wide/119457

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@xxxxxxxxxx


== 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.



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx
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-announce@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux