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

Project Discussion Change Proposals
,
1

Make OpenSSL distrust SHA-1 signatures by default

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.

Wiki
Announced

:link: Summary

OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.

:link: Owner

:link: 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.

:link: 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 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.

:link: Benefit to Fedora

Fedora’s security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape.

:link: 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.

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:

:link: 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.

:link: 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 asosedkin/sha1sig-tracer Copr. One would need openssl-3.2.1-9.fc41 or newer for the tool to work.

:link: 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.

:link: Dependencies

All reverse dependencies of openssl are potentially affected.

:link: 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.

:link: Documentation

SHA1SignaturesGuidance contains relevant notes. Fedora packaging guidelines should be modified accordingly.

:link: 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.

Last edited by @amoloney 2024-06-07T22:49:43Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Removed f37

4

I object to the term “deprecate” here, because if SHA-1 signatures will be rejected under the default configs, that’s more than a deprecation. (My understanding is, SHA-1 is already deprecated as a crypto algorithm for security purposes, isn’t it? I thought it joined MD5 in the Great Crypto Dustbin In The Ether, a while back.)

I’m not saying it isn’t the right time to turn off support entirely (even if only by default), but we shouldn’t describe that as merely a deprecation. It’s being disabled, turned off, support discontinued. Bereft of life, it squawks no more. If we 'adn’t nailed it to its perch, it’d be pushing up the daisies!

5

I agree that the text in the detailed description should be altered to be what the title and other parts of the document states (“distrust”, “blocking”), or use some equivalent wording

Other than the editorial clarification, I strongly support the goal of removing SHA-1 support by default.

I wonder if the name of the legacy policy be something like FEDORA40-WITH-INSECURE-OPENSSL-SHA1 so that it is more clear what one is choosing to use (and it is less likely one will choose to use it without some understanding).

6

My train of thoughts was more like “we want to deprecate as in phase out, and the next step in this long process of phasing out SHA-1 signatures of usage is rejecting them by default when this specific OpenSSL API is used”. I see your point though, hope it’s OK to make such edits at this point: Changes/OpenSSLDistrustSHA1SigVer: Difference between revisions - Fedora Project Wiki

7

This change proposal has now been submitted to FESCo with ticket #3229 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like
8

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

1 Like
9

Hello, could it be that this change accidentally broke DNSSEC algo 5 validation? Fedora DNSSEC default crypto policies and SHA1

10

This is just unfortunate, systemd-resolved is not ready for SHA-1 disabling at DNSSEC. It fails to behave correctly with any unsupported algorithms, probably including any future ones. Like post quantum algorithm experiments.

What I am still missing to a library call in openssl, which would return boolean status on digest algorithm support for signature verification. We needed to make special loop jumps to get it behave correctly in bind and unbound. In DNSSec, we need algorithm support decision before even fetching keys. Obviously systemd did not implement such loop holes yet.

Filled:

We had issues with it in RHEL9 and had to fix it somehow. Does not seem this were tested by systemd people similar way.