Craig Gallek [Wed, 11 Aug 2021 16:54:37 +0000 (12:54 -0400)]
x509: pin/password callback support for openssl encrypted private keys
This attempts to use the registered pin callback when the password for
an encrypted openssl private key is not supplied. This matches the
functionality for PKCS8 sealed keys above and is similar to what openssl
does in this situation.
Daiki Ueno [Mon, 2 Aug 2021 16:32:28 +0000 (18:32 +0200)]
pk: add flags to force RSA-PSS salt length to match digest length
This adds a couple of flags to RSA-PSS signing and verification, to
enforce that the salt length matches the digest length. That is not
only recommended in RFC 4055, but also mandated in RFC 8446 in the TLS
1.3 context.
Previously, we restricted RSA modulus size to be either 2048 or 3072
bits in FIPS mode, following FIPS 186-4. On the other hand, FIPS
140-2 IG A.14 and FIPS 140-3 IG C.F updates it to allow arbitrary
modulus sizes equal to or larger than 2048 bits under certain
conditions.
This change reflects the guidance, though it only allows known sizes
due to the complexity of calculating the approximate security strength
using the formula in FIPS 140-2 IG 7.5.
Suggested-by: Stephan Mueller Reviewed-by: Stephan Mueller Signed-off-by: Daiki Ueno <ueno@gnu.org>
gnutls_ocsp_resp_verify: Check key purpose if signer not on trust list
According to [1] the id-kp-OCSPSigning key purpose is only needed for
delegated signers, not signers explicitly set as trusted. The previous
code would reject a signature directly from a CA on the trust list
(without delegation) because the CA certificate didn't contain the
id-kp-OCSPSigning key purpose.
The tests included in this commit check:
1. Is a signature directly from a CA on the trust list accepted?
2. Is a signature from a delegated signer issued by a CA on the trust
list accepted?
3. Is a signature from a certificate without id-kp-OCSPSigning issued
by a CA on the trust list rejected?
Note that the CA in these tests is also the one that issued the
certificate the OCSP response is for, but the code (current and
previous) doesn't enforce this.
Daiki Ueno [Fri, 25 Jun 2021 06:39:12 +0000 (08:39 +0200)]
key_share: treat X25519 and X448 as same PK type when advertising
Previously, if both X25519 and X448 groups were enabled in the
priority string, the client sent both algorithms in a key_share
extension, while it was only capable of handling one algorithm from
the same (Edwards curve) category. This adds an extra check so the
client should send either X25519 or X448.
* guile/src/core.c (write_to_session_record_port) [USING_GUILE_BEFORE_2_2]:
Keep looping upon GNUTLS_E_AGAIN and GNUTLS_E_INTERRUPTED.
(write_to_session_record_port) [!USING_GUILE_BEFORE_2_2]: Loop on
GNUTLS_E_INTERRUPTED and return -1 on GNUTLS_E_AGAIN if C_SESSION is
backed by a file descriptor.
* NEWS: Update.
DN components are expected to be ordered by scale, with the wire format
representing larger-scale components (like country or organization) before
smaller-scale components (like state or organizationalUnit).
The bulk of the changes here of course are changes to the target
certificates in the test suite.
Note that a change was necessary in tests/cert-tests/crq.sh because it
tests the "interactive" mode of certtool. If any user is scripting
certtool in this way, this change will cause a backwards-incompatible
break. However, I think this is OK -- the supported scripted/batch
mode for certtool should use a template file, and I don't think it's
important to maintain a strict api on the interactive mode.
The main change here is to order the DN from least-specific-to-most,
in particular:
country, state, locality, org, orgunit, cn, uid
But I've also made an additional arbitrary choice, which is that DC
(domain component) comes *after* uid. This was already the case in
certificate generation, but in *request* generation, it was the other
way around. I've changed request generation to match this ordering
from certificate generation.
Closes: #1243 Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Daiki Ueno [Thu, 27 May 2021 08:00:22 +0000 (10:00 +0200)]
build: fix interface version dependencies in libgnutls.map
Previously, the predecessor of GNUTLS_3_7_0 was mistakenly set to
GNUTLS_3_4 instead of GNUTLS_3_6_14. This fix shouldn't have any
impact on ABI, given the dynamic loader doesn't take into account of
ordering of versions. See also the first paragraph on:
https://www.akkadia.org/drepper/dsohowto.pdf#page=38
When a certificate has a policy attached but no policyQualifiers,
`certtool` should omit the policyQualifiers sequence entirely, rather
than emitting an empty sequence.
Closes: #1238 Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Daiki Ueno [Fri, 14 May 2021 13:59:37 +0000 (15:59 +0200)]
cert auth: filter out unsupported cert types from TLS 1.2 CR
When the server is advertising signature algorithms in TLS 1.2
CertificateRequest, it shouldn't send certificate_types not backed by
any of those algorithms.
Daiki Ueno [Mon, 17 May 2021 05:58:43 +0000 (07:58 +0200)]
pre_shared_key: limit 0-RTT to resumption connections
While RFC 8446 allows 0-RTT data in a non-resumption connection
established with external PSK, it requires a mechanism to associate
encryption parameters with PSK. Until we provide a new API for that,
let's limit the 0-RTT use to resumption connections only.
x509: Write keyUsage extension with minimal BIT STRING
Avoid embedding trailing cleared bits in the BIT STRING for the
keyUsage extension.
The overwhelming majority of this changeset is correcting the
artifacts in the test suite, most of which had keyUsage with a
non-minimal encoding. The only functional code change is in
lib/x509/x509_ext.c.
Closes: #1236 Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Daiki Ueno [Fri, 14 May 2021 06:26:37 +0000 (08:26 +0200)]
serv: stop setting AI_ADDRCONFIG on getaddrinfo
AI_ADDRCONFIG is only useful when the NODE argument is given in the
getaddrinfo call, as described in RFC 3493 6.1. Suggested by Andreas
Metzler in:
https://gitlab.com/gnutls/gnutls/-/issues/1007#note_356637206
Daiki Ueno [Thu, 13 May 2021 13:03:10 +0000 (15:03 +0200)]
configure.ac: specify -ladvapi32 in mingw builds
This library needs to be linked for CryptAcquireContextW, used in
lib/system/keys-win.c. Suggested by Tim Kosse in:
https://gitlab.com/gnutls/gnutls/-/issues/1232
This allows the tests to set the current time to arbitrary point,
instead of the current time; useful for the tests checking the traces
such as tls13/prf-early.
gnutls_init: redefine GNUTLS_ENABLE_EARLY_DATA flag for client
The flag was only for the server, but it turned out to be useful for
client to explicitly indicate early data, when 0-RTT is handled
out-of-band as in QUIC.
Daiki Ueno [Tue, 11 May 2021 12:23:45 +0000 (14:23 +0200)]
gnutls-serv: use only async-signal-safe functions in signal handler
Spotted by gcc analyzer:
serv.c:1138:9: warning: call to 'exit' from within signal handler [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler]
1138 | exit(1);
| ^~~~~~~
Daiki Ueno [Tue, 11 May 2021 12:13:45 +0000 (14:13 +0200)]
certtool: tighten allocation check
Spotted by gcc analyzer:
certtool-cfg.c:856:24: warning: use of possibly-NULL 'copy' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
856 | while (strcmp(pass, copy) != 0
| ^~~~~~~~~~~~~~~~~~
Daiki Ueno [Tue, 11 May 2021 12:08:33 +0000 (14:08 +0200)]
psktool: tighten allocation check
Spotted by gcc analyzer:
psk.c:275:21: warning: use of possibly-NULL '_username.data' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
275 | if (strncmp(p, (const char *) _username.data,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
spelling: The possessive pronoun "its" has no apostrophe.
"it's" is for contractions like "it is" or "it has". "its" is a
possessive pronoun, like "his" or "hers" or "theirs", none of which
have an apostrophe in them either.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
certtool: Align warning about --provable with actual code
If I try to generate an ed25519 key, it is *not* an ECDSA key. But I
see this warning:
0 dkg@host:~$ certtool --generate-privkey --provable --key-type ed25519
Generating a 256 bit EdDSA (Ed25519) private key ...
The --provable parameter cannot be used with ECDSA keys.
1 dkg@host:~$
Looking at the code and documentation, it's clear that --provable only
works for RSA and DSA. This fix aligns the warning message with the
underlying mechanism.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Daiki Ueno [Mon, 3 May 2021 14:35:43 +0000 (16:35 +0200)]
x509/verify: treat SHA-1 signed CA in the trusted set differently
Suppose there is a certificate chain ending with an intermediate CA:
EE → ICA1 → ICA2. If the system trust store contains a root CA
generated with the same key as ICA2 but signed with a prohibited
algorithm, such as SHA-1, the library previously reported a
verification failure, though the situation is not uncommon during a
transition period of root CA.
This changes the library behavior such that the check on signature
algorithm will be skipped when examining the trusted root CA.
projects / thirdparty / gnutls.git / log
