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
