| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The callers know the actual length and can initialise a CBS correctly.
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
| |
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
| |
The code for dtls1_dispatch_alert() and ssl3_dispatch_alert() is largely
identical - with a bit of reshuffling we can use ssl3_dispatch_alert() for
both protocols and remove the ssl_dispatch_alert function pointer.
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When DTLS handshake records are received from the next epoch, we will
potentially queue them on the unprocessed_rcds queue - this is usually
a Finished message that has been received without the ChangeCipherSuite
(CCS) message (which may have been dropped or reordered).
After the epoch increments (due to the CCS being received), the current
code processes all records on the unprocessed queue and immediate queues
them on the processed queue, which dtls1_get_record() then pulls from.
This form of processing only adds more complexity and another queue.
Instead, once the epoch increments, pull a single record from the
unprocessed queue and process it, allowing the contents to be consumed
by the caller. We repeat this process until the unprocessed queue is
empty, at which point we go back to consuming messages from the wire.
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
| |
All this code does is read one byte from memory with an unknown length,
potentially being a one byte overread... and then nothing is actually done
with the value.
ok tb@
|
|
|
Now that the DTLS structs are opaque, add a dtls_locl.h header and move
internal-only structs from dtls1.h, along with prototypes from ssl_locl.h.
Only pull this header in where DTLS code actually exists.
ok inoguchi@ tb@
|
