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 <vondr...@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: asose...@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-le...@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-le...@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 | | |
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
