Carlos Garcia Campos authored Aug 26, 2015 and Carlos Garcia Campos committed Sep 28, 2015

We are currently checking every certificate in the chain and also
looking for an issuer in the database for the last certificate of the
chain. Now build_certificate_chain is called recursively so that for all
issuers that fail, we also try to find an issuer in the database,
instead of just for the last one. Pinned certificates are now handled by
the caller since they are done only once for the first certificate.
This fixes the case of fbcdn-dragon-a.akamaihd.net for which all the
certificates in the chain are not anchored, but we can find an issuer in
the database for the second certificate that is anchored.

https://bugzilla.gnome.org/show_bug.cgi?id=750457

As per the upstream discussion [1], session data should only be
stored when the session is not resumed.

This affects resuming sessions when using TLS tickets, since they
are not stored in the session data after a save/resume cycle.

[1] http://lists.gnutls.org/pipermail/gnutls-help/2015-February/003760.html

https://bugzilla.gnome.org/show_bug.cgi?id=745099

This is probably no longer needed for compatibility because nowadays
GnuTLS prioritizes ECDHE and RSA key exchange over DHE.

Note that GnuTLS currently defaults to allowing 728-bit DH parameters,
which are still very insecure. However, this is their policy to change.

https://bugzilla.redhat.com/show_bug.cgi?id=1177964#c8

2.42.1 and 2.43.1 use a gnutls-3.0-only function, so we were already
implicitly requireing gnutls 3.0 again. And the licensing problems
from before should now be resolved, since gmp has been relicensed to
LGPLv3+/GPLv2+. So switch the gnutls requirement back to 3.0.

https://bugzilla.gnome.org/show_bug.cgi?id=742750

Iain Lane authored Dec 10, 2014 and Dan Winship committed Dec 13, 2014

https://bugzilla.gnome.org/show_bug.cgi?id=741331

This bug will be fixed in 3.3.11

The handshake-while-simultaneously-reading-and-writing tests fail with
certain gnutls releases due to a gnutls bug, so skip it when compiling
against those releases.

Change the default "priority" string from "NORMAL:%COMPAT" to
"NORMAL:%COMPAT:%LATEST_RECORD_VERSION". (Correctly-implemented
servers won't care either way, but apparently some servers have been
incorrectly updated for POODLE-safeness by rejecting all handshakes
with SSL 3.0 in the version field [which had long been recommended for
compatibility reasons], even if the handshake offered to negotiate TLS
versions too.)

Change the fallback/"ssl3" priority code so that it never includes
%LATEST_RECORD_VERSION, but does include %COMPAT even if the default
priority doesn't (eg, because it was overridden with
G_TLS_GNUTLS_PRIORITY).

https://bugzilla.gnome.org/show_bug.cgi?id=740087

If SSL 3.0 is disabled, then make "use-ssl3" mean "use the lowest
available TLS version" instead, so that, eg, TLS 1.2 -> TLS 1.0
fallback is still possible.

https://bugzilla.gnome.org/show_bug.cgi?id=738633

Just to be on the safe side, ensure every private member of
GTlsConnectionGnutls is freed when the object itself is finalised.

implicit_handshake must always be NULL when finalize() is reached, as it
holds a reference to the GTlsConnectionGnutls as its source object.
However, it’s better to clear the member anyway, just in case this
behaviour changes in future.

https://bugzilla.gnome.org/show_bug.cgi?id=736809

https://bugzilla.gnome.org/show_bug.cgi?id=737106

https://bugzilla.gnome.org/show_bug.cgi?id=737106

We add a new intermediate CA and a new server certificate signed by this
new CA. Unit tests verify that the chain is loaded successfully and that
the old behavior is kept by loading a file with an invalid chain.

https://bugzilla.gnome.org/show_bug.cgi?id=729739

To help with debugging.

https://bugzilla.gnome.org/show_bug.cgi?id=736757

To help with debugging.

https://bugzilla.gnome.org/show_bug.cgi?id=736757

And a missing default case. This introduces no functional changes.

https://bugzilla.gnome.org/show_bug.cgi?id=736809

https://bugzilla.gnome.org/show_bug.cgi?id=736809

gcc prefers them this way round — the other way round is old-style.

https://bugzilla.gnome.org/show_bug.cgi?id=736809

See the implementation of g_io_stream_close()

https://bugzilla.gnome.org/show_bug.cgi?id=735754

Some TLS servers improperly send an unordered chain of certificates,
where the next certificate in the chain is not the issuer of the current
certificate. Recent versions of GnuTLS will verify the chain anyway to
help reduce unnecessary validation failures (since there is no security
risk in doing so).

When the certificates are unordered, get_peer_certificate_from_session()
will construct GTlsCertificates with incorrect issuer fields, causing
trouble with unordered chains even though GnuTLS would otherwise handle
these fine.

https://bugzilla.gnome.org/show_bug.cgi?id=683266

Refactor g_tls_certificate_gnutls_verify_identity() and extend the IP
address altname code to handle GInetSocketAddress identities as well.

Extend tls/tests/certificate.c to check that case as well, and also
check that incorrect IP addresses (as GNetworkAddress or
GInetSocketAddress) fail to verify.

Aleix Conchillo Flaqué authored Jul 18, 2014 and Dan Winship committed Jul 21, 2014

Updated server certificate by adding a X509v3 Subject Alternative Name
using an IP address.

A test case to verify that the IP is a valid identity for that
certificate has been added.

https://bugzilla.gnome.org/show_bug.cgi?id=726596

Aleix Conchillo Flaqué authored Mar 17, 2014 and Dan Winship committed Jul 21, 2014

If a network address is given and the IP can not resolve to a hostname
we now check it with the X509v3 Subject Alternate Name IP
fields (GNUTLS_SAN_IPADDRESS).

https://bugzilla.gnome.org/show_bug.cgi?id=726596