Since Mbed TLS 4.0, this is just the low-level error code. But keep the
combination for uniformity with the rest of the file, and to reduce the
differences with the 3.6 branch.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.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>
In test cases for pathLenConstraint parsing in a basicConstraints extension
of an X.509 certificate, use the standard type for the leading cA field,
namely BOOLEAN. The test data was encoding that field as INTEGER, which was
accepted as a deviation from the standard since XySSL 0.9.
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>
Previously this was tested indirectly by comparing driver vs reference
components in analyze-outcomes.py, but now that the number of exceptions
is low, it's much more efficient to test this directly.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Also remove the "no USE_PSA" tests: they are not executed, and are not
useful for the future - when we add support for restartable ECDH in TLS,
we can just use the existing tests and update the assertions, which
we'll have to do anyway (the tests being removed were asserting about
a legacy crypto function that no longer exists).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Try to load the list of tests that TF-PSA-Crypto wants us to ignore in three
ways, depending on the age of the tf-psa-crypto submodule:
* Modern: import `tf_psa_crypto_test_case_info` as an ordinary module,
expected to be found in `tf-psa-crypto/scripts/project_knowledge`.
* First location, quickly superseded: load
`tf-psa-crypto/tests/scripts/tf_psa_crypto_test_case_info.py`,
in a hackish way because we don't want to put that directory on the
load path.
* Oldest: there is no `tf_psa_crypto_test_case_info.py`. Use a hard-coded
list.
Once all the TF-PSA-Crypto branches we care about (e.g. pull requests
in progress) are updated with
`tf-psa-crypto/scripts/project_knowledge/tf_psa_crypto_test_case_info.py`,
we can drop the backward compatibilty hacks and simply
`import tf_psa_crypto_test_case_info` unconditionally and use
`tf_psa_crypto_test_case_info.INTERNAL_TEST_CASES` unconditionally.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This way, when Mbed TLS's `analyze_outcomes.py` loads the python module from
TF-PSA-Crypto (because it needs to know the value of `INTERNAL_TEST_CASES`),
there's no risk that the subproject and the superproject will have different
requirements on auxiliary modules such as `mbedtls_framework.outcome_analysis`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If we can't read `INTERNAL_TEST_CASES` from
`tf-psa-crypto/tests/scripts/analyze_outcomes.py` because the script doesn't
exist, hard-code the legacy value of that information.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If the `tf-psa-crypto` submodule has `tests/scripts/analyze_outcomes.py`,
require it to define a global variable `INTERNAL_TEST_CASES`. Those test
cases will be ignored in Mbed TLS's coverage analysis.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In DTLS reassembly tests, the server may receive a close_notify alert at the
end of a test. In this case, the Mbed TLS server logs an error, so these tests
should not check for the absence of the string "error" in the server logs.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Any `all.sh` component that runs a script that requires a more recent
version of Python must have a `support_xxx` function that checks for the
requisite Python version or package. At this time, there is no such
requirement yet in the mbedtls repository.
The directory `framework/util` is not yet checked by `pylint` or `mypy`,
because we use older versions of these tools that don't work well with
modern Python versions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
DEBUG_C supposed to have been removed from the test dependencies, still
being there is an oversight. Removing it was the sole purpose of
3e58109fbd.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The unit test framework always loads the client key as well, which
requires a different curve and a hash than the server key.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Add a test case with a successful handshake for each test case that
causes the desired handshake failure, with minimal differences between
the two.
The reason is to have more assurance that the handshake is failing for
the desired reason (as opposed to not having done something correctly in
the test code).
Signed-off-by: Janos Follath <janos.follath@arm.com>
There are other issues that can fail with the same error code. Make sure
that the handshake fails exactly the way we want it to fail by analysing
the client logs.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We usually follow the pattern that a zero-initialised struct is safe to
free. This wasn't the case here.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This root certificate uses SECP-384 and if we don't have it in the
build, the parsing already fails even if we don't try to use it, there
is no reason to have it in the build without the SECP-384.
Signed-off-by: Janos Follath <janos.follath@arm.com>
In testcases where we are expecting handshake failure the message
"Certificate verification was skipped" is not printed, so do not check
for it.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Check for the 'Certificate verification was skipped' message only when
the testcase depends on
MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED since in other
cases certificates may not be enabled at all and this message will not
be printed in the output.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Move a bunch of files from `scripts` and `mbedtls/scripts` to the framework.
Most are not called from any scripts invoked by the CI, but a couple are.
A subsequent commit will adapt the scripts. None of these scripts are
referenced from other repositories except in documentation.
The following files will be removed, and added to `mbedtls-framework`:
* `scripts/ecp_comb_table.py`
* `scripts/massif_max.pl`
* `tests/scripts/audit-validity-dates.py` (moved to `scripts/`)
* `tests/scripts/gen_ctr_drbg.pl` (moved to `scripts/`)
* `tests/scripts/gen_gcm_decrypt.pl` (moved to `scripts/`)
* `tests/scripts/gen_gcm_encrypt.pl` (moved to `scripts/`)
* `tests/scripts/gen_pkcs1_v21_sign_verify.pl` (moved to `scripts/`)
* `tests/scripts/generate-afl-tests.sh` (moved to `scripts/`)
* `tests/scripts/generate_server9_bad_saltlen.py` (moved to `scripts/`)
* `tests/scripts/run-metatests.sh` (moved to `scripts/`)
* `tests/scripts/run_demos.py` (moved to `scripts/`)
* `tests/scripts/test_config_script.py` (moved to `scripts/`)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We haven't used this in years. It's obsolete because this functionality
should now be provided by the more general PSA function
wrappers (`PSALoggingWrapper` generator), although that work is unfinished.
It belongs in TF-PSA-Crypto anyway. So remove it, it's one less little
amount of baggage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In testcases in opt-testcases/tls13kex-modes.sh, check for the setting
of the failure flag MBEDTLS_X509_BADCERT_SKIP_VERIFY by looking for the
string "! Certificate verification was skipped" in the output in cases
where the key exchange is negotiated to use PSK.
Note that this check for output is only added to the success cases since
the negative tests fail before this string is printed.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Check that the message "! Certificate verification was skipped" is
present in the output when auth_mode=none. This indicates that the
certificate verify flag MBEDTLS_X509_BADCERT_SKIP_VERIFY was
correctly set.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The recursion tests for the crypto code
are run in a TF-PSA-Crypto component.
No need to run them in an Mbed TLS
component as well.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In `test_suite_debug`, test `mbedtls_debug_snprintf()`, which uses
`mbedtls_vsnprintf()` like `mbedtls_debug_print_msg()`. Do this instead of
testing `mbedtls_snprintf()`, which might be subtly different (older
Windows runtimes had slightly different behavior for vsnprintf() vs
snprintf(); TF-PSA-Crypto might pick up a different function if the
platform configuration is different in TF-PSA-Crypto and Mbed TLS).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Relax the dependencies of the tests about handshake
message defragmentation/reassembly on server side.
TLS 1.3 does not need to be enable anymore for this
to work for TLS 1.2 handshake messages.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Improve DTLS proxy 3d tests with OpenSSL and
GnuTLS servers. Have a better control of which
message is fragmented and verify it is the
case.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Improve DTLS reassembly tests with OpenSSL
and GnuTLS server. Check that some messages
have been reassembled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
We are about to have full support for TLS 1.2
CH reassembly on server side. The equivalent
positive test would be a duplicate of one of
the tests generated by generate_tls_handshake_tests.py.
Thus just removing the negative test.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The generated unit tests have the input parameters in large stack
buffers and therefore ASan doesn't notice under or overflows in them.
Copy the input parameter into a locally allocated buffer to trigger ASan
if something goes wrong.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Initialize the verify_result field in mbedtls_ssl_session_free().
Previously we were just zeroising the entire session object, which would
yield a default 'success' value if the same object were reused.
Test that this initialisation is actually happening by setting
verify_result manually to zero and calling mbedtls_ssl_session_free() on
the session before checking its value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Since we explicitly document the value 0xFFFFFFFF or -1u as representing
'result not available', we can use it as a sensible default value
without creating an API change. Use this value instead of introducing a
new verification result value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Write a testcase to get verify_result before we have performed a
handshake and make sure that it is initialised to a failure value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
