Re: Schedule for Monday's FESCo Meeting (2021-08-23)

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

 



On Tue, Aug 24, 2021 at 8:57 PM przemek klosowski via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> On 8/23/21 5:49 AM, Alexander Sosedkin wrote:
> > Sure. Crypto-policies are there to give you control of what's enabled,
> > ideally what's enabled by default.
> >
> > 1) There's a blanket `update-crypto-policies --set LEGACY`
> > 2) There's a possibility to reenable disabled algorithms with custom policies,
> >     allowing to go even lower than LEGACY (which you
> >     shouldn't really do on public networks, but who's there to stop you)
> > 3) (F35+) There's a possibility to reenable algorithms per backends,
> >     say, for NSS, Java or krb5 only
> > 4) (In an ideal world) crypto-policies settings should act as defaults,
> >     meaning apps should be able to further modify them,
> >    offer weaker methods with a warning, etc
> It's not ideal if one obsolete website forces downgrading the security
> potentially for all the connections. I hope 5) is addressing that.

That's something apps and only apps can handle.

> > 5) There are total per-backend opt-out mechanisms / procedures
> What is the 'backend' in this context? Since the protocol downgrades are
> required by obsolete endpoints to which we're trying to connect, you're
> suggesting 'per IP' or 'per-subnet' opt-out, right? Does it require
> creating separate network interfaces and custom routes?

Slow down.
"Backend" = component crypto-policies generates configuration for:
openssl, krb5, java to name a few.
`ls /etc/crypto-policies/back-ends`
If apps want to do something per IP, subnet, domain etc,
they need to handle the required downgrades themselves.
Crypto-policies are just for setting defaults system-wide
in a uniform fashion by controlling configuration files.
Thus narrow deviations from these defaults are way out of scope.

> > 4 is what broke it here (gnutls currently uses hard-denylisting),
> > but, in general, you still have all the other ways.
> > They aren't something we can recommend to all openconnect users,
> > but we've compromised on not-hard-disabling DTLS 0.9 specifically
> > until we fix 4 more thoroughly.
> >
> > If an administrator of the specific host wants to modify or bypass
> > crypto-policies, it's entirely within their power to do so
> > and nobody intends (or is able to, for that matters) hinder that.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




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

  Powered by Linux