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

[Clemens Lang]

Hello Daniel,

> On 5. Jul 2024, at 15:33, Daniel P. Berrangé  wrote:
> 
> It isn't listed there, but it certainly should be, as we've not
> been considering it FIPS compliant, for precisely this reason.

OK. I’ve asked our docs team to add it to the list. Thank you for bringing this 
to my attention.


> FYI, disabling FIPS was done by the upstream maintainer, it isn't a
> downstream change.

We can’t force upstream to care about FIPS, but as RHEL downstream we should. 
This may occasionally mean shipping downstream changes or submitting patches to 
make such things configurable.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat



-- 
___
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

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

[Daniel P . Berrangé]

On Fri, Jul 05, 2024 at 02:59:36PM +0200, Clemens Lang wrote:
> Hi,
> 
> > On 5. Jul 2024, at 14:49, Daniel P. Berrangé  wrote:
> > 
> > On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote:
> >> 
> >> 
> >> Please start addressing this with whoever maintains the TPM specification.
> > 
> > The TPM spec is maintained by the Trusted Computing Group, and I have
> > no influence there.
> 
> You could try to bring it up with them, on a mailing list, for example. Have 
> you tried?

Would be lovely if they had a mailing list, or a place to file bugs,
but AFAICT it is a closed industry members only group with no formal
way to give feedback as an outsider.

Perhaps could find someone at IBM who could do it on our behalf.

In addition I've learnt that Windows 11 is still creating TPM
based keys using a SHA-1 algorithm for something related to
TPM key attestation :-(

> >> SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this
> >> change is already broken in FIPS mode, and the deprecation of SHA-1 will
> >> only continue to cause more and more problems.
> > 
> > swtpm works around that be unconditionally disabling FIPS mode in openssl
> > already.
> > 
> > This is fine, because the guest OS can put itself in FIPS mode, which
> > will prevent it from using the undesirable algorithms, even if the TPM
> > exposes them.
> 
> No, this is a misconception. FIPS mode does not just disable algorithms,
> it also enables additional selftests and code paths, and changes the
> behavior of random number generators and key generation.
> 
> If your guest OS is in FIPS mode and uses cryptography from swtpm, that
> cryptography is still not FIPS compliant, and you should not misrepresent
> it to be. In fact, we should probably add it to the list of packages that
> do not use FIPS compliant cryptography in RHEL at [1, 2] if it isn’t on
> there yet.

It isn't listed there, but it certainly should be, as we've not
been considering it FIPS compliant, for precisely this reason.

> Please don’t make such decisions (for RHEL) without talking to
> the crypto team. On Fedora, we don’t make any claims as to
> FIPS-ness of the operating system, so it’s fine there, but
> probably also not a great idea.

FYI, disabling FIPS was done by the upstream maintainer, it isn't a
downstream change.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

-- 
___
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

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

[Clemens Lang]

Hi,

> On 5. Jul 2024, at 14:49, Daniel P. Berrangé  wrote:
> 
> On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote:
>> 
>> 
>> Please start addressing this with whoever maintains the TPM specification.
> 
> The TPM spec is maintained by the Trusted Computing Group, and I have
> no influence there.

You could try to bring it up with them, on a mailing list, for example. Have 
you tried?


>> SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this
>> change is already broken in FIPS mode, and the deprecation of SHA-1 will
>> only continue to cause more and more problems.
> 
> swtpm works around that be unconditionally disabling FIPS mode in openssl
> already.
> 
> This is fine, because the guest OS can put itself in FIPS mode, which
> will prevent it from using the undesirable algorithms, even if the TPM
> exposes them.

No, this is a misconception. FIPS mode does not just disable algorithms, it 
also enables additional selftests and code paths, and changes the behavior of 
random number generators and key generation.

If your guest OS is in FIPS mode and uses cryptography from swtpm, that 
cryptography is still not FIPS compliant, and you should not misrepresent it to 
be. In fact, we should probably add it to the list of packages that do not use 
FIPS compliant cryptography in RHEL at [1, 2] if it isn’t on there yet.

Please don’t make such decisions (for RHEL) without talking to the crypto team. 
On Fedora, we don’t make any claims as to FIPS-ness of the operating system, so 
it’s fine there, but probably also not a great idea.


>> An alternative is to run swtpm with OPENSSL_CONF in the environment
>> pointing to an alternative openssl configuration file that re-enables
>> SHA-1. You could maintain this configuration file together with swtpm.
> 
> Can custom openssl config files "inherit"  from the primary one.
> ie can we have a config file that just references the primary,
> while toggling only the sha1 setting, so we're not overriding
> all the openssl config settings ?

The OpenSSL configuration file format has an include directive, so you may be 
able to set this up.


[1]: 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#ref_list-of-rhel-applications-using-cryptography-that-is-not-compliant-with-fips-140-2_using-the-system-wide-cryptographic-policies
[2]: 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#ref_list-of-rhel-applications-using-cryptography-that-is-not-compliant-with-fips-140-3_using-the-system-wide-cryptographic-policies



-- 
Clemens Lang
RHEL Crypto Team
Red Hat



-- 
___
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

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

[Daniel P . Berrangé]

On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote:
> Hi,
> 
> > On 5. Jul 2024, at 12:38, Daniel P. Berrangé  wrote:
> > 
> > I've (re-)discovered that this change is going to impact on swtpm that is
> > used with QEMU to provide a virtual TPM to guests.
> > 
> > The TPM2 specification has fully crypto agility, however, the sha1
> > algorithm is one of the few that is declared mandatory to implement.
> > Though it is documented as deprecated by the spec, we need to provide
> > it to be compliant.
> 
> Please start addressing this with whoever maintains the TPM specification.

The TPM spec is maintained by the Trusted Computing Group, and I have
no influence there.

> SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this
> change is already broken in FIPS mode, and the deprecation of SHA-1 will
> only continue to cause more and more problems.

swtpm works around that be unconditionally disabling FIPS mode in openssl
already.

This is fine, because the guest OS can put itself in FIPS mode, which
will prevent it from using the undesirable algorithms, even if the TPM
exposes them.

> > The 'runcp' command is really particularly nice as a solution though.
> > Using that in a non-interactive scenario will require modifying the
> > software that launches swtpm to wrap its execution.  Or we have to
> > replace the swtpm binary with a shell script that invokes the real
> > binary indirectly, which isn't especially nice either, as wrapper
> > shell scripts often require then changing the selinux policy to
> > allow their use.
> 
> An alternative is to run swtpm with OPENSSL_CONF in the environment
> pointing to an alternative openssl configuration file that re-enables
> SHA-1. You could maintain this configuration file together with swtpm.

Can custom openssl config files "inherit"  from the primary one.
ie can we have a config file that just references the primary,
while toggling only the sha1 setting, so we're not overriding
all the openssl config settings ?

> > The change proposal talks about an API being added to openssl to
> > allow this to be changed programmatically, which is really what
> > I would like to see, so that swtpm can just request SHA1, as this
> > has the lowest impact.
> 
> The upstream work on this is stalled, both due to my lack of time
> and upstream’s requests to change it fundamentally twice after I
> had working implementations. I wouldn’t rely on this showing up
> any time soon. I still want to eventually finish it, but until
> that happens and then gets released in a new OpenSSL version,
> this doesn’t exist.
> 
> 
> > Until that exists, however, I'm inclined
> > to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup,
> > despite the warnings not to do this.
> 
> As announced, we’re going to break that without regard for whether you used 
> it, and it won’t make a difference in FIPS mode.
> You should really use a separate openssl configuration file using 
> OPENSSL_CONF instead, and start a discussion to get the TPM standard updated.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

-- 
___
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

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

[Clemens Lang]

Hi,

> On 5. Jul 2024, at 12:38, Daniel P. Berrangé  wrote:
> 
> I've (re-)discovered that this change is going to impact on swtpm that is
> used with QEMU to provide a virtual TPM to guests.
> 
> The TPM2 specification has fully crypto agility, however, the sha1
> algorithm is one of the few that is declared mandatory to implement.
> Though it is documented as deprecated by the spec, we need to provide
> it to be compliant.

Please start addressing this with whoever maintains the TPM specification. 
SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this 
change is already broken in FIPS mode, and the deprecation of SHA-1 will only 
continue to cause more and more problems.

See also 
https://fedoraproject.org/wiki/SHA1SignaturesGuidance#Cryptographic_immobility_or_outdated_standards.


> The 'runcp' command is really particularly nice as a solution though.
> Using that in a non-interactive scenario will require modifying the
> software that launches swtpm to wrap its execution.  Or we have to
> replace the swtpm binary with a shell script that invokes the real
> binary indirectly, which isn't especially nice either, as wrapper
> shell scripts often require then changing the selinux policy to
> allow their use.

An alternative is to run swtpm with OPENSSL_CONF in the environment pointing to 
an alternative openssl configuration file that re-enables SHA-1. You could 
maintain this configuration file together with swtpm.


> The change proposal talks about an API being added to openssl to
> allow this to be changed programmatically, which is really what
> I would like to see, so that swtpm can just request SHA1, as this
> has the lowest impact.

The upstream work on this is stalled, both due to my lack of time and 
upstream’s requests to change it fundamentally twice after I had working 
implementations. I wouldn’t rely on this showing up any time soon. I still want 
to eventually finish it, but until that happens and then gets released in a new 
OpenSSL version, this doesn’t exist.


> Until that exists, however, I'm inclined
> to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup,
> despite the warnings not to do this.

As announced, we’re going to break that without regard for whether you used it, 
and it won’t make a difference in FIPS mode.
You should really use a separate openssl configuration file using OPENSSL_CONF 
instead, and start a discussion to get the TPM standard updated.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat



-- 
___
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

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

[Daniel P . Berrangé]

On Mon, Jun 10, 2024 at 08:40:22PM +0200, Clemens Lang wrote:
> Hi,
> 
> > On 10. Jun 2024, at 20:16, Richard W.M. Jones  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)***.

I've (re-)discovered that this change is going to impact on swtpm that is
used with QEMU to provide a virtual TPM to guests.

The TPM2 specification has fully crypto agility, however, the sha1
algorithm is one of the few that is declared mandatory to implement.
Though it is documented as deprecated by the spec, we need to provide
it to be compliant.

I don't really want to tell people to change global crypto policies
because there is alot of software in the virt host OS stack that
uses crypto and should remain protected by the strong default crypto
settings.

The 'runcp' command is really particularly nice as a solution though.
Using that in a non-interactive scenario will require modifying the
software that launches swtpm to wrap its execution.  Or we have to
replace the swtpm binary with a shell script that invokes the real
binary indirectly, which isn't especially nice either, as wrapper
shell scripts often require then changing the selinux policy to
allow their use.

The change proposal talks about an API being added to openssl to
allow this to be changed programmatically, which is really what
I would like to see, so that swtpm can just request SHA1, as this
has the lowest impact. Until that exists, however, I'm inclined
to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup,
despite the warnings not to do this.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

-- 
___
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

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

[Petr Pisar]

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


signature.asc
Description: PGP signature
--
___
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

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

[Leon Fauster via devel]

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.




--
Leon
--
___
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

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

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

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  wrote:

> Hi Peter,
>
> > On 11. Jun 2024, at 07:01, Peter Boy  wrote:
> >
> >> Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones :
> >>
> >> 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-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
>


-- 
Dmitry Belyavskiy
--
___
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

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

[Clemens Lang]

Hi Peter,

> On 11. Jun 2024, at 07:01, Peter Boy  wrote:
> 
>> Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones :
>> 
>> 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-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

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

[Peter Boy]

> Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones :
> 
> 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
p...@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



--
___
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

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

[Clemens Lang]

Hi,

> On 10. Jun 2024, at 20:16, Richard W.M. Jones  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)***.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


--
___
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

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

[Alexander Sosedkin]

On Mon, Jun 10, 2024 at 8:16 PM Richard W.M. Jones  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-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: 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, 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 

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

[Richard W.M. Jones]

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-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: 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, 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/12

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

[Leslie Satenstein via devel]

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$4$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  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 increas

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

[Alexander Sosedkin]

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$4$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  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-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: 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, 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.
> >
>

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

[Vít Ondruch]

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-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: 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, 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 cry

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

[Clemens Lang]

Hi Björn,


> On 9. Jun 2024, at 00:37, Björn Persson  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.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


--
___
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: 

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

[Clemens Lang]

Hi Vitaly,

> On 9. Jun 2024, at 09:15, Vitaly Zaitsev via devel 
>  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.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


--
___
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

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

[Dmitry Belyavskiy]

Dear Roberto

On Sun, Jun 9, 2024 at 1:16 PM Roberto Ragusa  wrote:

> On 6/9/24 11:27, Dmitry Belyavskiy wrote:
> >
> > On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@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?).
>

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.

-- 
Dmitry Belyavskiy
--
___
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

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

[Roberto Ragusa]

On 6/9/24 11:27, Dmitry Belyavskiy wrote:


On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek mailto:zbys...@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



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.
--
   Roberto Ragusamail at robertoragusa.it
--
___
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

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

[Dmitry Belyavskiy]

On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek <
zbys...@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

-- 
Dmitry Belyavskiy
--
___
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

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

[Dmitry Belyavskiy]

Dear Björn,

On Sun, Jun 9, 2024 at 12:39 AM Björn Persson  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 14 SHA-1-signed domains. That's only 6‰ of the signed
> domains, but still a rather large absolute number.
>

I don't think that 14 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.

-- 
Dmitry Belyavskiy
--
___
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

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

[Zbigniew Jędrzejewski-Szmek]

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
--
___
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

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

[Dominique Martinet]

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)

-- 
Dominique Martinet | Asmadeus
--
___
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

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

[Vitaly Zaitsev via devel]

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.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
--
___
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

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

[Björn Persson]

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


pgpX_oba2_qyt.pgp
Description: OpenPGP digital signatur
--
___
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

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

[Aoife Moloney]

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: 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, 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

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

[Aoife Moloney]

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: 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, 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