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>
Erroring on a symmetric-key type would actually be an extra line of
code.
In theory we could try to save that one line of code, but it is
premature optimisation at this point. Also, this is a predominantly
asymmetric crypto feature, it is less confusing/more user friendly if we
don't allow symmetric keys here.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We shouldn't return PSA_SUCCESS from a function that isn't implemented.
PSA_ERROR_NOT_SUPPORTED seems like the most appropriate return status
for a function that isn't implemented.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Reassure both humans and compilers that the places where we assign an
integer to a smaller type are safe.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
Add a practical way to fill the dynamic key store by artificially limiting
the slice length through a test hook.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
