Reject malformed TLS 1.3 serialized sessions instead of accepting
unterminated strings or extra trailing data, and reject serialized SSL
contexts whose DTLS Connection ID length exceeds the maximum supported
size instead of overflowing the internal buffer.
Backport of #10715 (development).
Signed-off-by: Nadav0077 <18245584+Nadav0077@users.noreply.github.com>
Fix a TLS 1.2 client regression that caused valid ServerKeyExchange signatures using rsa_pss_rsae_* to be rejected.
Allow rsa_pss_rsae_* in the TLS 1.2 client ServerKeyExchange parse path when the algorithm is supported and was offered by the client. Add OpenSSL and GnuTLS interoperability coverage for TLS 1.2 servers that force rsa_pss_rsae_sha256.
Fixes#10668.
Signed-off-by: Viktor Sokolovskiy <maokaman@gmail.com>
We were using slightly different guards to decide whether to include
`<unistd.h>` in different places. Unify those.
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>
We do not return failure, but return -1u which is documented as a value
that indicates that the result is not available.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Even though the TLS RFCs do not mandate libraries to expose *Error
Alerts* (as defined in RFC8446 6.2 for TLS 1.3 and in RFC5246 7.2.2 for
TLS 1.2) to the user, there are use cases when it is handy to get the
actual last received fatal error instead of a generic one. For instance
this enables the user to differ between received fatal errors in case
`mbedtls_ssl_handshake()`, `mbedtls_ssl_handshake_step()` or
`mbedtls_ssl_read()` returned `MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE`.
This changesets stores the last incoming fatal alert in
`mbedtls_ssl_context` and provides `mbedtls_ssl_get_alert()` as a getter
for retrieving it. Another option would be to provide a callback
mechanisms for all kinds of alerts (not only fatals) but for simplicity
I discarded this option.
Signed-off-by: Nico Geyso <ng@gsmk.de>
