Although, this function acts on the message provided as expected and thus
it should never call a message parsing function on unexpected
messages, we make a more explicit sanity check. This unifies the
sanity checks existing within the involved functions.
Daiki Ueno [Sat, 9 Feb 2019 09:26:56 +0000 (10:26 +0100)]
ext/supported_versions: regenerate server random
This adds a call to _gnutls_gen_server_random() in handling the
"supported_versions" extension, so that the TLS 1.3 downgrade sentinel
is set only when the earlier versions are selected.
Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>
This revert also contains the fix to the original commit (invalid
utf8->utf16 conversion) and a minor simplification of the _treaddir loop.
Tim Rühsen [Wed, 6 Feb 2019 10:30:06 +0000 (11:30 +0100)]
gnutls-cli: Fix --starttls-proto=xmpp
Fixes two issues with gnutls-cli --starttls-proto=xmpp:
1. Print 'Timeout' on timeout instead of random errno message
2. Do not wait for linefeed when using XMPP (XML)
Daiki Ueno [Fri, 8 Feb 2019 13:46:33 +0000 (14:46 +0100)]
gnutls_record_set_max_size: make it work on server side
The record_size_limit extension can also be specified by the server to
indicate the maximum plaintext. Also add test cases for asymmetric
settings between server and client.
Daiki Ueno [Fri, 8 Feb 2019 12:22:13 +0000 (13:22 +0100)]
ext/record_size_limit: account for content type octet in TLS 1.3
In TLS 1.3, the protocol maximum of plaintext size is 2^14+1, while
it is 2^14 in TLS 1.2. To accommodate that, this introduces the
following invariant:
- when the maximum is set by the user with
gnutls_record_set_max_size(), store it as is. The value range is
[511, 16834].
- when the maximum is negotiated through record_size_limit extension,
it can be [512, 16385]. In TLS 1.3, subtract by 1 to fit in [511,
16384].
Daiki Ueno [Thu, 17 Jan 2019 10:53:35 +0000 (11:53 +0100)]
ext/record_size_limit: don't confuse with negotiated/user-supplied maximum
As documented in gnutls_int.h, max_record_send_size is for tracking
the user-supplied maximum, while max_record_recv_size for the
protocol negotiated maximum.
Daiki Ueno [Sun, 20 Jan 2019 08:18:21 +0000 (09:18 +0100)]
ext/max_record: server shouldn't send it with record_size_limit
Otherwise, the connection will be disconnected by the client, as
suggested in RFC: A client MUST treat receipt of both
"max_fragment_length" and "record_size_limit" as a fatal error, and it
SHOULD generate an "illegal_parameter" alert.
x509: corrected issue in the algorithm parameters comparison
Each certificate has two fields to set the signature algorithm
and parameters used for the digital signature. One of the fields is
authenticated and the other is not. It is required from RFC5280 to
enforce the equality of these fields, but currently due to an issue
we wouldn't enforce the equality of the parameters fields. This
fix corrects the issue.
We also move an RSA-PSS certificate in chainverify that was relying
on invalid parameters, to this set of invalid certificates.
Tim Rühsen [Mon, 11 Feb 2019 09:41:47 +0000 (10:41 +0100)]
Fix 32bit overflow issue in src/serv-args.def
Fixing this warning seen on 32bit architectures:
serv-args.c: In function 'doOptMaxearlydata':
serv-args.c:1431:14: warning: overflow in conversion from 'long long int' to 'long int' changes value from '4294967296' to '0' [-Woverflow]
{ 1, 4294967296 } };
^~~~~~~~~~
bootstrap: refuse to bootstrap if any dependencies bring gnulib's network stack
If gnulib's network stack is brought (due to a dependency) in the library
it will make the library unusable to non-gnulib using applications. This
prevents windows applications for example to use gnutls, and so on. Even
more it is quite hard to catch that issue because our testsuite uses
gnulib as well. Instead we try to catch the these modules at import time.
Fallback to TLS 1.2 when incompatible with signature certs are provided
This only takes into account certificates in the credentials structure.
If certificates are provided in a callback, these must be checked by
the provider. For that we assume that the credentials structure is
filled when associated with a session; if not then the fallback mechanism
will not work and the handshake will fail.
Enforce the certificate key usage restrictions on all cases
That is, we require a signing certificate when negotiating
TLS1.3, or when sending a client certificate (on all cases).
Before we would not perform any checks under TLS1.3 or when client
certificates are sent, assuming that the certificates used will always
be signing ones. However if the user sets up incorrectly a decryption
certificate we would use it for signing. This fix makes sure that an
error is returned early when these scenarios are detected.
This adds a set of policies regarding issues and merge requests
to be enforced by the gitlab-triage bot. That is:
- Issues without any label for more than a month are marked
with needs attention label
- Issues with needinfo label are closed if they are not updated
within a month
- Merge requests marked as WIP with no update within 5 months
are closed.
These rules are not enforced automatically; we have to schedule
a run of the gitlab-triage bot.
build: do not generate mech-list.h if p11-kit is not available
Compiling GnuTLS with no p11-kit installed will result in a serie of
warnings during build time because mech-list.h will be generated even if
pkcs11 tool compilation is disabled. Move mech-list.h generation to
happen only if pkcs11 is enabled, thus removing these warnings.
Alon Bar-Lev [Sun, 27 Jan 2019 11:17:35 +0000 (13:17 +0200)]
build: detect previous supported guile
A recent change in the m4 macro of guile enforces latest guile:
---
AC_DEFUN([GUILE_PROGS],
[_guile_required_version="m4_default([$1], [$GUILE_EFFECTIVE_VERSION])"
if test -z "$_guile_required_version"; then
_guile_required_version=2.2
fi
---
The result:
---
checking for guile-snarf... /usr/bin/guile-snarf
checking for guild... /usr/bin/guild
checking for guile-2.2... no
checking for guile2.2... no
checking for guile-2... no
checking for guile2... no
checking for guile... /usr/bin/guile
checking for Guile version >= 2.2... configure: error: Guile 2.2 required, but 2.0.14 found
---
Probably best to specify the supported version explicitly when calling
GUILE_PROGS, to keep existing behavior calling the GUILE_PKG detects the
existing packages.
projects / thirdparty / gnutls.git / log
