Fiona Klute [Sun, 14 Jun 2020 10:52:46 +0000 (12:52 +0200)]
Wipe session ticket keys before releasing the session structure
This includes both a copy of the master key and one or two derived
keys, all of which could be used to decrypt session tickets if
stolen. The derived keys could only be used for tickets issued within
a certain time frame (by default several hours).
The documentation for gnutls_session_ticket_enable_server() already
states that the master key should be wiped before releasing it, and
the same should apply to internal copies.
Daiki Ueno [Tue, 9 Jun 2020 08:41:18 +0000 (10:41 +0200)]
tests: check_for_datefudge: don't exit the test programs
This makes check_for_datefudge not to immediately exit the program,
but to return non-zero to allow the tests by themselves to control the
behavior when "datefudge" is not found.
Vitezslav Cizek [Tue, 9 Jun 2020 11:54:04 +0000 (13:54 +0200)]
configure: improve nettle, gmp, and hogweed soname detection
Some linkers might optimize away the libraries passed on the
command line if they aren't actually needed, such as gnu ld with
--as-needed.
The ldd output then won't list the shared libraries and the
detection will fail.
Make sure nettle and others are really used.
Daiki Ueno [Mon, 8 Jun 2020 04:45:24 +0000 (06:45 +0200)]
configure.ac: prefer the latest version of build infrastructure
AM_GNU_GETTEXT_REQUIRE_VERSION tells autopoint to copy the latest
possible build infrastructure installed on the system, rather than the
fixed version from the archive.dir.tar.xz. This makes the
bootstrapping slightly faster and allows us not to stick with the
ancient gettext version.
Steve Lhomme [Sat, 6 Jun 2020 12:05:16 +0000 (14:05 +0200)]
Merge the extra libraries to link dynamically in GNUTLS_LIBS_PRIVATE
This should fix #1020 where bcrypt is missing from thirdparty_libadd.
Ultimately it would be good to add libraries that always need to be linked in
one variable that is shared between the Makefile and the pkg-config file.
Daiki Ueno [Fri, 5 Jun 2020 14:26:33 +0000 (16:26 +0200)]
crypto-api: always allocate memory when serializing iovec_t
The AEAD iov interface falls back to serializing the input buffers if
the low-level cipher doesn't support scatter/gather encryption.
However, there was a bug in the functions used for the serialization,
which causes memory leaks under a certain condition (i.e. the number
of input buffers is 1).
This patch makes the logic of the functions simpler, by removing a
micro-optimization that tries to minimize the number of calls to
malloc/free.
The original problem was reported by Marius Steffen in:
https://bugzilla.samba.org/show_bug.cgi?id=14399
and the cause was investigated by Alexander Haase in:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1277
Daiki Ueno [Tue, 2 Jun 2020 18:53:11 +0000 (20:53 +0200)]
stek: differentiate initial state from valid time window of TOTP
There was a confusion in the TOTP implementation in stek.c. When the
mechanism is initialized at the first time, it records the timestamp
but doesn't initialize the key. This removes the timestamp recording
at the initialization phase, so the key is properly set later.
Daiki Ueno [Tue, 2 Jun 2020 03:38:28 +0000 (05:38 +0200)]
gnutls_cipher_init: fix potential memleak
Upon failure this function returns without freeing memory allocated
internally. This makes sure that it is released and do not touch the
output handle argument.
Daiki Ueno [Mon, 1 Jun 2020 15:23:59 +0000 (17:23 +0200)]
serv: omit upper bound of --maxearlydata option definition
It turned out that AutoGen treats numbers that exceed INT_MAX in a
platform dependent way. In this case, 4294967295 (UINT_MAX) is
treated as is on 64-bit platforms, while it is interpreted as "-1" on
32-bit platforms. This causes a problem when the program
documentation is compiled under multilib environment.
Reported by Ivan Molodetskikh in:
https://bugzilla.redhat.com/show_bug.cgi?id=1841844
and the cause was identified by Anderson Toshiyuki Sasaki.
Daiki Ueno [Sun, 31 May 2020 11:59:53 +0000 (13:59 +0200)]
x509: trigger fallback verification path when cert is expired
gnutls_x509_trust_list_verify_crt2 use the macro SIGNER_OLD_OR_UNKNOWN
to trigger the fallback verification path if the signer of the last
certificate is not in the trust store. Previously, it doesn't take
into account of the condition where the certificate is expired.
Daiki Ueno [Sun, 31 May 2020 10:39:14 +0000 (12:39 +0200)]
_gnutls_pkcs11_verify_crt_status: check validity against system cert
To verify a certificate chain, this function replaces known
certificates with the ones in the system trust store if possible.
However, if it is found, the function checks the validity of the
original certificate rather than the certificate found in the trust
store. That reveals a problem in a scenario that (1) a certificate is
signed by multiple issuers and (2) one of the issuers' certificate has
expired and included in the input chain.
This patch makes it a little robuster by actually retrieving the
certificate from the trust store and perform check against it.
Daiki Ueno [Mon, 25 May 2020 16:37:51 +0000 (18:37 +0200)]
gnulib: update git submodule
This brings in the new fopen-gnu module and the RF_SENSITIVE flag for
fread_file and read_file. This also adds the following changes to be
consistent with the latest changes in Gnulib:
- the callers of fread_file and read_file to be adjusted for the FLAGS
argument
- "attribute.h" needs to be used extensively
Steve Lhomme [Wed, 27 May 2020 21:13:43 +0000 (21:13 +0000)]
configure.ac: determine if the Vista APIs can be linked statically
If _WIN32_WINNT is higher or equal to 0x0600, Vista API's are allowed during
the build. We can assume that the minimum platform the code will run on is
Vista [1]
In that case there's no need to call API's (ncrypt) dynamically when it can be
done statically.
Dmitry Baryshkov [Tue, 26 May 2020 10:12:24 +0000 (13:12 +0300)]
tests: build datefudge-check during make all
Most of the tests depend on datefudge-check. Let's make it during 'make
all' stage to allow running individual tests w/o requiring to build it
separately.
Dmitry Baryshkov [Thu, 14 May 2020 02:54:58 +0000 (05:54 +0300)]
build: vendor in libtasn1 code
Instead of keeping the minitasn1 source in Git, vendor in it during
bootstrap as we do with Nettle code. This also upgrades included
minitasn1 to latest version (4.16.0).
Steve Lhomme [Tue, 19 May 2020 14:23:40 +0000 (16:23 +0200)]
win32: link with crypt32
Since 5d03564cccd2c10c41252ea468d4a098bd08e9c1 we use CertOpenStore().
To properly link it needs to be linked with the crypt32.dll.
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certopenstore
This library was missing from the pkg-config library. It exists in
thirdparty_libadd to link gnutls as a DLL.
Daiki Ueno [Tue, 19 May 2020 14:18:39 +0000 (16:18 +0200)]
fips: remove FIPS_STARTUP_ONLY_TEST_CASE macro
The macro was intended to avoid non-recoverable errors during library
initialization, but the code path has been removed in commit 3963518d067a64412bbe0aa9ce5fc33ae729c15f.
Daiki Ueno [Mon, 18 May 2020 10:25:42 +0000 (12:25 +0200)]
fips: make FIPS140-2 mode enablement logic simpler
Previously, to enable the FIPS140-2 mode, both /etc/system-fips and
the fips=1 kernel command line need to be set. While this was
designed to be consistent, the convention is not well followed by the
other crypto libraries and the former tends to be ignored. This
aligns the behavior to the latter, i.e. if fips=1 is set, the library
enables the FIPS140-2 mode regardless of the existence of
/etc/system-fips.
Daniel Lenski [Sun, 17 May 2020 21:50:47 +0000 (14:50 -0700)]
refine tests for ancient servers which support both SSL 3.0 and TLS 1.0, but both only with %NO_EXTENSIONS
This is a follow-up to !1221.
See #958 and https://gitlab.com/openconnect/openconnect/-/issues/145 for a
real-world example of ancient Cisco servers with these deficiencies.
With !1221 only, gnutls-cli-debug reports that these ancient servers only support
SSL 3.0 (but without extensions). Information after this point is
largely erroneous:
$ gnutls-cli-debug ***vpn.***.com
GnuTLS debug client 3.6.12
Checking ***vpn.***.com:443
whether the server accepts default record size (512 bytes)... no
whether %ALLOW_SMALL_RECORDS is required... no
for SSL 3.0 (RFC6101) support... yes
for SSL 3.0 with extensions... no
With this additional change, gnutls-cli-debug correctly reports that such a
server also supports TLS 1.0 (but again with extensions disabled). Below
I've marked some of the significant fields that have changed:
$ gnutls-cli-debug ***vpn.***.com
GnuTLS debug client 3.6.12
Checking ***vpn.***.com:443
whether the server accepts default record size (512 bytes)... no
whether %ALLOW_SMALL_RECORDS is required... no
for SSL 3.0 (RFC6101) support... yes
for SSL 3.0 with extensions... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes
# This is now correct:
whether we need to disable TLS 1.0... no
# This is now correct:
whether %NO_EXTENSIONS is required... yes
# This is now correct:
for TLS 1.0 (RFC2246) support... yes
for TLS 1.1 (RFC4346) support... no
fallback from TLS 1.1 to... failed
for TLS 1.2 (RFC5246) support... no
# This is now correct:
for known TLS or SSL protocols support... yes
TLS1.2 neg fallback from TLS 1.6 to... failed (server requires fallback dance)
for inappropriate fallback (RFC7507) support... no
for HTTPS server name... ******
for certificate chain order... sorted
for Safe renegotiation support (SCSV)... no
for version rollback bug in RSA PMS... no
for version rollback bug in Client Hello... no
whether the server ignores the RSA PMS version... no
whether small records (512 bytes) are tolerated on handshake... yes
whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted... yes
whether the server understands TLS closure alerts... partially
whether the server supports session resumption... yes
for anonymous authentication support... no
for ephemeral Diffie-Hellman support... no
for RFC7919 Diffie-Hellman support... no
for AES-GCM cipher (RFC5288) support... no
for AES-CCM cipher (RFC6655) support... no
for AES-CCM-8 cipher (RFC6655) support... no
for AES-CBC cipher (RFC3268) support... no
for CAMELLIA-GCM cipher (RFC6367) support... no
for CAMELLIA-CBC cipher (RFC5932) support... no
# This is now correct:
for 3DES-CBC cipher (RFC2246) support... yes
# This is now correct:
for ARCFOUR 128 cipher (RFC2246) support... yes
for CHACHA20-POLY1305 cipher (RFC7905) support... no
for GOST28147-CNT cipher (draft-smyshlyaev-tls12-gost-suites) support... no
for MD5 MAC support... yes
for SHA1 MAC support... yes
for SHA256 MAC support... no
for GOST28147-IMIT MAC (draft-smyshlyaev-tls12-gost-suites) support... no