[gnutls-devel] GnuTLS 3.6.0 released

[Nikos Mavrogiannopoulos]

On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote:
>> We are proud to announce a new GnuTLS release: Version 3.6.0.
>>
>> GnuTLS is a modern C library that implements the standard network
>> security protocol Transport Layer Security (TLS), for use by network
>> applications.  GnuTLS is developed for GNU/Linux, but works on many
>> Unix-like systems as well as Windows.
>>
>> The GnuTLS library is distributed under the terms of the GNU Lesser
>> General Public License version 2 (or later).
>>
>> The project pages of the library are available at:
>> http://www.gnutls.org/
>
> [snip]
>
>> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification
>>    of certificates signed with SHA1 is now considered insecure and will
>>    fail, unless flags intended to enable broken algorithms are set. Other uses
>>    of SHA1 are still allowed. This can be reverted on compile time with the configure
>>    flag --enable-sha1-support.
>
> FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will
> be generating certs that will never validate, since that API is hardcoded to
> use SHA1.  This tripped up the libvirt & QEMU test suites which used that API.
> I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256
> explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign()
> to use SHA256 too, or must it stick with SHA1 for backcompat reasons ?

It is documented as signing with SHA1, so changing will introduce a
behavioral "breakage", though I am not sure whether it matters in the
end.

> If so, it would be worth putting a note in the API docs that any use of
> gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted.

The options seem to be:
 * deprecate the API and force applications specify explicitly a hash
for signing
 * Update/break the ABI for 3.6 and make the underlying algorithm used
to be undefined (i.e., a secure but unspecified one).

I kind of like the second option, as applications may hard-code a
digest which will bring the problem back when that hash is broken. Any
other opinions/options?

regards,
Nikos

PS. I have still not managed to run the libvirt and openconnect test
suites under CI. gitlab runners for some reason cannot detect errors
from fedpkg and a failing build is detected as successful. I'd
appreciate any help on that item.
https://gitlab.com/gnutls/gnutls/merge_requests/477
https://gitlab.com/gnutls/gnutls/-/jobs/29756798