Defragment DTLS.
authorjsing <jsing@openbsd.org>
Tue, 31 Aug 2021 13:34:55 +0000 (13:34 +0000)
committerjsing <jsing@openbsd.org>
Tue, 31 Aug 2021 13:34:55 +0000 (13:34 +0000)
commit49c081a03cd8415bb7ff887e4c7b07f7e5ddf1a2
tree66c07156cf2f30591a0eb4255d4e5bb75aa856b7
parent686958b66615237caea8d7ad6523db3d14b4097a
Defragment DTLS.

In normal TLS, it is possible for record fragments to be sent that contain
one byte of alert or handshake message payload. In this case we have to
read and collate multiple message fragments before we can decide what to
do with the record.

However, in the case of DTLS, one record is effectively one packet and
while it is possible to send handshake messages across multiple
records/packets, the minimum payload is the DTLS handshake message header
(plus one byte of data if the handshake message has a payload) - without
this, there is insufficient information available to be able to reassemble
the handshake message. Likewise, splitting an alert across multiple DTLS
records simply does not work, as we have no way of knowing if we're
collating the same alert or two different alerts that we lost half of each
from (unfortunately, these details are not really specified in the DTLS
RFC).

This means that for DTLS we can expect to receive a full alert message
(a whole two bytes) or a handshake record with at least the handshake
message header (12 bytes). If we receive messages with less than these
lengths we discard them and carry on (which is what the DTLS code already
does).

Remove all of the pointless fragment handling code from DTLS, while also
fixing an issue where one case used rr->data instead of the handshake
fragment.

ok inoguchi@ tb@
lib/libssl/d1_pkt.c
lib/libssl/dtls_locl.h