Make DTLS behave like TLS when negotiating version: record layer has
DTLS 1.0, message version is 1.2.
Tolerate different version numbers if version hasn't been negotiated
yet.
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.
As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.
Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.
Add code to d1_pkt.c to send message headers to the message callback.
Kludge alert. This is arranged by passing padding length in unused
bits of SSL3_RECORD->type, so that orig_len can be reconstructed.
(cherry picked from commit 8bfd4c659f180a6ce34f21c0e62956b362067fba)
This change updates the DTLS code to match the constant-time CBC
behaviour in the TLS.
(cherry picked from commit 9f27de170d1b7bef3d46d41382dc4dafde8b3900)
The previous CBC patch was bugged in that there was a path through enc()
in s3_pkt.c/d1_pkt.c which didn't set orig_len. orig_len would be left
at the previous value which could suggest that the packet was a
sufficient length when it wasn't.
(cherry picked from commit 6cb19b7681f600b2f165e4adc57547b097b475fd)
This change adds CRYPTO_memcmp, which compares two vectors of bytes in
an amount of time that's independent of their contents. It also changes
several MAC compares in the code to use this over the standard memcmp,
which may leak information about the size of a matching prefix.
(cherry picked from commit 2ee798880a246d648ecddadc5b91367bee4a5d98)
Thanks to Antonio Martin, Enterprise Secure Access Research and
Development, Cisco Systems, Inc. for discovering this bug and
preparing a fix. (CVE-2012-0050)
(Firstly... ommitted)
Secondly, it wasn't even _dropping_ the offending packets, in the
non-blocking case. It was just returning garbage instead.
PR: #1752
Submitted by: David Woodhouse <dwmw2@infradead.org>