Fix bug in handling of DTLS client hard reconnect
We keep track of the current epoch and record sequence number in out_ctr,
which was overwritten when writing the record containing the
HelloVerifyRequest starting from out_buf. We can avoid that by only using the
rest of the buffer.
Using MBEDTLS_SSL_MAX_CONTENT_LEN as the buffer size is still correct, as it
was a pretty conservative value when starting from out_buf.
Note: this bug was also fixed unknowingly in 2.13 by introducing a new buffer
that holds the current value of the sequence number (including epoch), while
working on datagram packing: 198594709baa82d55bba4e5ee442ffb5ffe886b4
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
diff --git a/ChangeLog b/ChangeLog
index b4d2d44..9e0abd7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -2,6 +2,15 @@
= mbed TLS x.x.x branch released xxxx-xx-xx
+Security
+ * Fix bug in DTLS handling of new associations with the same parameters
+ (RFC 6347 section 4.2.8): after sending its HelloVerifyRequest, the
+ server would end up with corrupted state and only send invalid records to
+ the client. An attacker able to send forged UDP packets to the server
+ could use that to obtain a Denial of Service. This could only happen when
+ MBEDTLS_SSL_DTLS_CLIENT_PORT_REUSE was enabled in config.h (which it is
+ by default).
+
Bugfix
* Fix compilation failure when both MBEDTLS_SSL_PROTO_DTLS and
MBEDTLS_SSL_HW_RECORD_ACCEL are enabled.