It allows weak hash algorithms to be used in PKCS7. It's only added in the
LTS branch for backward compatibility, but it's disabled by default because
that's the safest choice.
This commit also updates test data in order to test the new build symbol.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Add a check on mbedtls_pkcs7_data_or_hash_verify() so that the verification
fails if the MD alg specified in PKCS7 structure or the signature
algorithm specified in the X.509 certificate are not in the list of
secure algorithms (i.e. mbedtls_x509_crt_profile_default).
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Following functions
- x509_profile_check_md_alg
- x509_profile_check_pk_alg
are made non-static and moved to x509_internal.h so that other library
files can used them.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
ssl_preset_default_hashes was removed in
f0cda410a4bca0f45f66bdbf0714cd0eb2ea4718 but the comment in 'x509_crt.c'
wasn't updated.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
In an X.509 certificate, a basicConstraints extension where the cA
field (BOOLEAN) is omitted but the pathLenConstraint field (INTEGER )is
present is syntactically valid, but RFC 5280 states that CAs MUST NOT emit
such a certificate.
Historically, since XySSL 0.9 in 2008, if a basicConstraints extension
started with an INTEGER field, we interpreted that field as a cA value. This
was a deliberate change:
> Fixed x509_get_ext() to accept some rare certificates (like
> www.openssl.org:443) which have an INTEGER instead of a BOOLEAN for
> Extension::BasicConstraints::cA.
However, 18 years later, this does not seem to be relevant, and the details
seem to have been lost. Furthermore, major implementations follow RFC 5280
and interpret `SEQUENCE { INTEGER n }` with cA being set to its default
value (FALSE) and pathLenConstraint set to `n`. This means that such a
certificate with n != 0 would be interpreted as a CA certificate in Mbed TLS
but as a leaf certificate elsewhere, which is dangerous.
Since CAs are not supposed to emit such certificates, stop accepting them
altogether.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It is now unreachable because:
- end_set == end_attr_data is enforced at library/x509_csr.c:236.
- end_exts == end_set is enforced at library/x509_csr.c:248.
- x509_csr_parse_extensions() only returns success if *p == end_exts, enforced
at library/x509_csr.c:188.
So after a successful x509_csr_parse_extensions() call, *p == end_exts ==
end_set == end_attr_data. The condition at line 257 cannot be true.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't allow parts of a compound (SEQUENCE or SET) to go beyond the
containing compound.
The inline CSR regression test is derived from the existing "X509 CSR
ASN.1 (OK)" DER test vector. In the extensionRequest attribute, the original
well-formed fragment is:
a029 3027 06092a864886f70d01090e 311a 3018 ...
where 31 1a is the SET containing the Extensions sequence and 30 18 is the
contained Extensions sequence. The malformed test changes only the SET
length byte, from 1a to 19:
a029 3027 06092a864886f70d01090e 3119 3018 ...
The attribute SEQUENCE length and the inner Extensions sequence length are
left unchanged. This makes the SET one byte too short for its containing
attribute, so the parser must reject it with
MBEDTLS_ERR_ASN1_LENGTH_MISMATCH instead of parsing the trailing byte as
data outside the SET.
There is no known security impact, just some risk reduction.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When parsing the basicConstraints extension, reject junk after the SEQUENCE
inside the extension (which is probably benign), and reject a SEQUENCE that
extends beyond the extension (could be very dangerous).
Add a non-regression test where a certificate that is technically malformed,
but accepted as a leaf certificate by OpenSSL and other X.509
implementations, to be accepted as a CA certificate by Mbed TLS.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reject HRR selected_group unless it matches the client’s original
supported_groups and is locally supported, so unadvertised groups are not
accepted in the second ClientHello.
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
This is required because if the user defined configuration file (not the
default one provided by mbedtls) includes files from the standard
C library then __STDC_WANT_LIB_EXT1__ won't be defined there which
cause weird build failures.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
When MBEDTLS_SSL_PROTO_TLS1_3 is enabled ensure that at least one of the
related key exchanges is also enabled.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
ECDHE-RSA only requires RSA signature, not encryption. This commits fixes
guards in "mbedtls_check_config.h".
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Fix a TLS 1.2 client regression that caused valid ServerKeyExchange signatures using rsa_pss_rsae_* to be rejected.
Allow rsa_pss_rsae_* in the TLS 1.2 client ServerKeyExchange parse path when the algorithm is supported and was offered by the client. Add OpenSSL and GnuTLS interoperability coverage for TLS 1.2 servers that force rsa_pss_rsae_sha256.
Fixes#10668.
Signed-off-by: Viktor Sokolovskiy <maokaman@gmail.com>
For each received ClientHello fragment, check
that its epoch is zero and update the
record-level sequence number.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
