Generally speaking, in this group of test we use O_SRV when testing our
client's behaviour, and O_CLI when testing our server's behaviour. I
don't think that's essential, but why not.
Well, for these two tests there's a reason why not: O_CLI often exits 0,
seemingly not minding that the server aborted the handshake with a fatal
alert, but sometimes it exits 1. (I've observed 0 on my machine, on two
runs of OpenCI and Internal CI, and 1 in some test in one run of
Internal CI.)
So, use our client instead, which exits non-zero consistently.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- cli-auth 1.2 was missing a test with an irrelevant bit set in addition
to the relevant bit (which was added for 1.3 previously)
- use consistent naming for fail (hard/soft)
Note: currently there are no "fail (soft)" cases for 1.3 authentication
of server by client, as server auth is mandatory in 1.3 (this will
change in 3.6.1).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previously the client was only printing them on handshake success, and
the server was printing them on success and some but not all failures.
This makes ssl-opt.sh more consistent as we can always check for the
presence of the expected message in the output, regardless of whether
the failure is hard or soft.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- consistent naming with explicit version
- in each section, have a positive case with just the needed bit set,
and one with an irrelevant bit set in addition (cli 1.3 only had the
former, and cli-auth 1.3 only the later)
- when auth_mode optional is supported failing cases should come in
pairs: soft+hard, this wasn't the case for cli-auth 1.3. (Note: cli 1.3
currently does not support auth_mode optional.)
- failing cases should check that the correct flag is printed and the
expected alert is sent.
The last (two) points have uncovered a bug in 1.3 code:
- In fail (hard) cases the correct alert isn't send, but a more generic
one instead.
- In fail (soft) cases the issue with the certificate is not reported,
actually the certificate is reported as valid.
Both share the same root cause: the flags are not updated properly when
checking the keyUsage extension. This will be addressed in future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In terms of line coverage, this was covered, except we never checked the
behaviour was as intended.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We were only testing the static key store (MBEDTLS_PSA_KEY_STORE_DYNAMIC
disabled) with configs/*.h. Add a component with the static key store and
everything else (including built-in keys), and a component with the static
key store and CTR_DBRG using PSA for AES (which means PSA uses a volatile
key internally).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
GNU Make 3.81 is officially not supported (we require >= 3.82), but be nice
to XCode users who are stuck with 3.81.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When PSA uses CTR_DRBG for its random generator and CTR_DRBG uses PSA for
AES, as currently implemented, there is one volatile key in permanent use
for the CTR_DRBG instance. Account for that in tests that want to know
exactly how many volatile keys are in use, or how many volatile keys can be
created.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make it possible, but not officially supported, to switch the CTR_DRBG
module to PSA mode even if MBEDTLS_AES_C is defined. This is not really
useful in practice, but is convenient to test the PSA mode without setting
up drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
