We were not making enough room. We want to move everything from the
place where we are going to insert the new record.
This was not causing failures because the code does not look at the
content after the inserted record, because it correctly returns an error
when seeing the inserted record. But as a matter on principle, the test
code should be doing what it says: just insert a new record but leave
a valid fragment after it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These are not optimal. For example, the tests should in principle be
able to run in builds without ECDSA, by using RSA certs instead. Ideally
PSK should work too.
However, getting optimal dependencies would be a lot of work that's
largely orthogonal to the purpose of this PR, so we'll settle for good
enough.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Simulate the server closing the connection after a partial handshake
message.
These test cases don't send a close_notify alert. The test cases
"insert alert record" exercise what happens if the server sends an alert.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create tests that coalesce the handshake messages in the first flight from
the server. This lets us test the behavior of the library when a handshake
record contains multiple handshake messages.
Only non-protected (non-encrypted, non-authenticated) handshake messages are
supported.
The test code works for all protocol versions, but it is only effective in
TLS 1.2. In TLS 1.3, there is only a single non-encrypted handshake record,
so we can't test records containing more than one handshake message without
a lot more work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is more flexible: the test data gets to decide whether we want to
assert the presence of a pattern or not.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This should avoid running into a bug with printf format specifiers one
windows.
It's also a logical move for actual tests: I used the highest debug
level for discovery, but we don't need that all the time.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Declare the same dependencies as for the previous TLS 1.3 tests, except
for part that varies with the cipher suite (ie AES-GCM).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This guards the definition of mbedtls_test_ssl_endpoint which we rely
on, so the function won't compile without it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Pre-existing but not having TLS 1.3 in the build does not seem to be
necessary actually. These test functions set the dtls flag when
calling `test_resize_buffers` and then `test_resize_buffers` sets the
`options.dtls` flag which eventually forces the TLS 1.2 version of the
protocol (in `mbedtls_test_ssl_endpoint_init()` call of
`mbedtls_ssl_config_defaults()` with `MBEDTLS_SSL_TRANSPORT_DATAGRAM`
as the transport).
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
Hanshake serialization requires that the selected ciphersuite uses
an AEAD algorithm. However, following the DHE-RSA removal, trying to
still use RSA signature might select a ciphersuite which is not using
AEAD, but CBC instead (see preference order in "ssl_ciphersuite.c").
This is especially problematic in tests scenarios where both GCM and
ChaChaPoly are disabled, so that CCM remains as the only AEAD algorithm.
Ciphersuites using RSA signature and CCM are very low on the preference
list, so very unlikely to be picked in tests. This cause a CBC one to
be selected in this case and the handshake_serialization() function
to fail.
In order to prevent failures from happening, in this commit we require
that either GCM or ChaChaPoly are enabled, so that ciphersuites using one
of these are likely to be picked.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
We should not manually set the TLS version, the tests are supposed to
pass in 1.3-only builds as well. Instead do the normal thing of setting
defaults. This doesn't interfere with the rest of the testing, so I'm
not sure why we were not doing it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Remove all code guarded by `PSA_WANT_ECC_SECP_K1_224`, which is not and will
not be implemented. (It would be K1_225 anyway, but we don't intend to
implement it anyway.)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
