Don't ship two slightly different wheels.
This reduces our platform adherence by using only `clock_gettime()` in the
library and not `gettimeofday()` as well.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Nowadays, the timing module just builds on a function that provides a timer
with millisecond resolution. In terms of platform requirements, this is
almost exactly equivalent to `mbedtls_ms_time()`
provides (`mbedtls_ms_time()` is arguably a little stronger because it is
supposed to last longer than a single timer object, but an application could
start a timer when it starts, so there's no real difference.) So it's a bit
silly that `timing.c` essentially reimplements this. Rely on
`mbedtls_ms_time()` instead.
This is an API break because in Mbed TLS 4.0, it was possible to enable
`MBEDTLS_TIMING_C` without `MBEDTLS_HAVE_TIME`. However, `timing.c` only
provided an implementation for Windows and Unix-like platforms, and on those
platforms, it is very likely that the default implementation of
`MBEDTLS_HAVE_TIME` would also work. (The main exception would be a platform
that has the traditional Unix function `gettimeofday()`, but not the 1990s
novelty `clock_gettime()`.) So make this an official requirement, as a
belated change that really should have gone into 4.0 if we'd taken the time
to dig into it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
In the TLS-Exporter for TLS 1.3 we mistakenly call PSA_HASH_LENGTH() on
an mbedtls_md_type_t when it should be called on a psa_algorithm_t.
Fortunately, these two types have almost the same values, since we have
previously aligned them to make conversion more efficient. As a result,
PSA_HASH_LENGTH() produces exactly the same value when called on an
mbedtls_md_type_t as with the equivalent psa_algorithm_t.
Thanks to this happy coincidence, fix a largely cosmetic issue (rather
than a major functional bug).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
TLS-PRF uses either SHA-256 and SHA-384, so the removed paragraph was not
correct. The correct version is already available few lines below in the
same header file.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
