On Wed, May 4, 2022 at 12:52 PM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
> On Wed, May 4, 2022 at 12:43 AM David Woodhouse <dwmw2(a)infradead.org> wrote:
>> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
>>> This is the reason why the proposal contains extensive methods to test
>>> whether things are going to break by modifying the crypto-policy or using
>>> bpftrace. Unfortunately there are hundreds of packages that depend on
>>> cryptographic libraries, and millions of different configurations out
there.
>>> We can’t know ahead of time which ones of them are going to break, but the
>>> proposal provides tools and a long transition period to identify and fix
>>> them.
>> When changes like this broke things for users in the past, we talked
>> about a way to present the "insufficient crypto/digest/protocol" as
>> just another failure like server certificate validation failures, so
>> the application/user can *choose* to accept and proceed, in real time.
>>
>> I'd like to see that as a *condition* of acceptance of further
>> restrictions in the policy.
>>
>> I really don't want us continuing to break things for Fedora users and
>> driving them back to the proprietary VPN clients.
>>
>> I am pleased to see some progress on this front with
>>
https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
>> clear to me that this gives us what we need. We *want* to warn users
>> that their VPN server doesn't meet modern crypto standards. We don't
>> want to just blindly re-enable ancient crap and have it silently work.
>> But we also do *need* it to work, after we've warned the user about it.
> If the error returned from GnuTLS isn't enough to infer
While I don't know much about GnuTLS, I have yet to see single OpenSSL
error message which would help user to understand the issue.
I was talking error codes, not error messages, but oof.
> that you should make the user opt-in into a legacy algorithm
> and then counter the restriction on the next attempt with
> a priority string extension or gnutls_protocol_mark_enabled,
> please file a bug with GnuTLS and describe your case.
> Your continued input would be appreciated.
> Same with the other libraries if you meant other libraries.
>
> If you don't want to spend a connection on just probing,
> but instead prefer to connect no matter what
> and then query what has been negotiated
> to make the warn/abort decisions on the application layer
> that should also be possible.
>
>> Which is why handling it like a certificate validation failure seems to
>> be the right answer, but I'm happy to explore other solutions... but
>> preferably *not* solutions like "manually set
>> GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
>> explicitly override all the Fedora crypto policies". That suggestion
>> made me sad... :)
> +1, this is not the way