If the server during a TLS 1.3 handshake selects
the PSK key exchange mode, it does not matter
if it did not find in the key share extension
a key share for a group it supports. Such a
key share is used and necessary only in the
case of the ephemeral or PSK ephemeral key
exchange mode. This is a possible scenario in
the case of a server that supports only the PSK
key exchange mode and a client that also
supports a key exchange mode with ephemeral keys.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
- Full tests generated by script only for ffdhe2048 group
- Single G->m and m->G exchange test for each other group
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Add FFDH support to the test case generator script: generate_tls13_compat_tests.py.
Add dependency for openssl as FFDH is supported from version 3.0.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Set hybrid TLS 1.2/1.3 as default server
configuration if both TLS 1.2 and TLS 1.3
are enabled at build time.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Force TLS 1.2 on TLS 1.2 specific tests in
preparation of TLS 1.3 being the default
protocol version when both TLS 1.2 and
TLS 1.3 are enabled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Force TLS 1.2 version on tests related to
MBEDTLS_SSL_ASYNC_PRIVATE, CA callback and
MBEDTLS_SSL_MAX_FRAGMENT_LENGTH. Those
SSL options are not supported in TLS 1.3
for the time being. Thus force TLS 1.2
version in preparation of TLS 1.3 being
the default protocol version when both
TLS 1.2 and TLS 1.3 are enabled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Remove unnecessary explicit MBEDTLS_SSL_PROTO_TLS1_2
dependency if TLS 1.2 version is forced or a TLS 1.2
cipher suite is forced (as TLS 1.2 cipher suites are
available if and only if TLS 1.2 is enabled and
cipher suite availability is check automatically).
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
After merging the driver only ECDSA work, a conflict arose between that and
the previous work re-ordering the ciphersuite preference list. We can remove
the breaking requirement on this test, as this requirement is now auto-detected
when the server5 crt is used in the server's command line.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
There were some dependencies that are now automatically satisfied by the
detect_required_features() function.
After this check there should be no redundant requirement for:
- requires_pk_alg "ECDSA"
- requires_any_configs_enabled $TLS1_2_KEY_EXCHANGES_WITH_ECDSA_CERT
- requires_any_configs_enabled $TLS1_2_KEY_EXCHANGES_WITH_CERT
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This was a leftover from some debug activity that unfortunately ended up
in previous commits.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Adjust where to set absolute path for MBEDTLS_TEST_OUTCOME_FILE
as it's supposed to set its absolute path after all possible
value assignment.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
This moslty focus on tests using "server5*" cerificate. Several cases
are taken into account depending on:
- TLS version (1.2 or 1.3)
- server or client roles
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Restore same PSK length enforcement in
conf_psk and set_hs_psk, whether the
negotiated protocol is TLS 1.2 or TLS 1.3.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
MBEDTLS_PSK_MAX_LEN main purpose is to determine
a miximum size for the TLS 1.2 pre-master secret.
This is not relevant to TLS 1.3 thus disable in
TLS 1.3 case the check against MBEDTLS_PSK_MAX_LEN
when setting during the handshake the PSK through
mbedtls_ssl_set_hs_psk(). This fixes the session
resumption with 384 bits PSKs when MBEDTLS_PSK_MAX_LEN
is smaller than that.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Per gnutls anti replay issue, it needs millionsecond time delay for
improve the fail rate.
From test result of #6712, this can improve the fail rate from 4%
to 92%.
Signed-off-by: Jerry Yu <jerry.h.yu@arm.com>
These variables were both uses to select the default version of OpenSSL
to use for tests:
- when running compat.sh or ssl-opt.sh directly, OPENSSL_CMD was used;
- when running all.sh, OPENSSL was used.
This caused surprising situations if you had one but not the other set
in your environment. For example I used to have OPENSSL_CMD set but not
OPENSSL, so ssl-opt.sh was failing in some all.sh components but passing
when I ran it manually in the same configuration and build, a rather
unpleasant experience.
The natural name would be OPENSSL, and that's what set in the Docker
images used by the CI. However back in the 1.3.x days, that name was
already used in library/Makefile, so it was preferable to pick a
different one, hence OPENSSL_CMD. However the build system has not been
using this name since at least Mbed TLS 2.0.0, so it's now free for use
again (as demonstrated by the fact that it's been set in the CI without
causing any trouble).
So, unify things and use OPENSSL everywhere. Just leave an error message
for the benefit of developers which might have OPENSSL_CMD, not OPENSSL,
set in their environment from the old days.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It might not be obvious that this option goes beyond adding new
functions, but also automagically modifies the behaviour of TLS
in some circumstances. Moreover, the exact modifications and
circumstances were not documented anywhere outside the ChangeLog.
Fix that.
While at it, adjust the test that checks no restartable behaviour with
other key exchanges, to use a key exchange that allows cert-based client
authentication so that we can check that this is not restartable either.
We don't have any automated test checking that the server is never
affected. That would require adding an ec_max_ops command-line option to
ssl_server2 that never has any effect, just to check that it indeed
doesn't. I'm not sure that's worth it. I tested manually and could
confirm that the server never has restartable behaviour, even for the
parts that are shared between client and server such as cert chain
verification.
Note (from re-reading the code): all restartable behaviour is controlled
by the flag ssl->handshake->ecrs_enabled which is only client-side with
the ECDHE-ECDSA key exchange (TLS 1.2).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Added mixed cases:
- server using opaque password, while client not
- client using opaque password, while server not
Added a test with mismatched passwords in case both server and
client are using opaque passwords (the same test was already
present for the non-opaque case)
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
We don't need to have two copies of the test with one of them depending
on legacy/compat CID: we can have just one copy, but make sure we run
ssl-opt.sh both in a build with standard CID and in a build with
legacy/compat - that's the job of all.sh (see next commit).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Per suggestion from Manuel, I removed this redundant test.
Signed-off-by: Hannes Tschofenig <hannes.tschofenig@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
OpenSSL may be configured to support features such as cipher suites or
protocol versions that are disabled by default. Enable them all: we're
testing, we don't care about enabling insecure stuff. This is not needed
with the builds of OpenSSL that we're currently using on the Jenkins CI, but
it's needed with more recent versions such as typically found on developer
machines, and with future CI additions.
The syntax to do that was only introduced in OpenSSL 1.1.0; fortunately we
don't need to do anything special with earlier versions.
With OpenSSL 1.1.1f on Ubuntu 20.04, this allows SHA-1 in certificates,
which is still needed for a few test cases in ssl-opt.sh. Curiously, this is
also needed for the cipher suite TLS-DHE-PSK-WITH-ARIA-128-GCM-SHA256 (and
no other, including other DHE-PSK or ARIA cipher suites).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The value of the first sent signature algorithm is overwritten.
This test forces only a single algorithm to be sent and then
validates that the client received such algorithm.
04 03 is the expected value for SECP256R1_SHA256.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
