Re: [openssl.org #2230] Resolved: [PATCH] DTLS reassembly

Robin Seggelmann via RT wrote: + for (ii = (((start) 3) + 1); ii (((end - 1)) 3); ii++) bitmask[ii] = 0xff; \ I guess there's a minor mistake: I recommend to replace (((end - 1)) 3) with (((end) - 1) 3) -Daniel

Re: [openssl.org #2230] Resolved: [PATCH] DTLS reassembly

Robin Seggelmann via RT wrote: #define RSMBLY_BITMASK_IS_COMPLETE(bitmask, msg_len, is_complete) { \ + if (is_complete) for (ii = (((msg_len) - 1) 3) - 1; ii 0 ; ii--) \ I'm wondering if there are two issues with this for loop: 1. It fails to check if bitmask[0]

[openssl.org #2221] [PATCH] DTLS Fragment reassembly

dtls1_process_out_of_seq_message() has two bugs: - Only one handshake message fragment per sequence number is saved. However, there may be multiple fragments with identical sequence numbers. All of them should be buffered. - Fragments with zero length are not saved. This is incorrect behavior

[openssl.org #2218] [Bug report] DTLS: dtls1_get_record() uses unauthenticated sequence number

d1_pkt.c:dtls1_get_record() processes DTLS records which it gets from the wire. At the same time, this function performs replay protection: It memorizes the (explicit) sequence numbers of the records and drops records that have already been processed. The sequence numbers of the processed

[openssl.org #2209] [PATCH] Error in man page BIO_should_retry(3)

I believe there's an error in man page BIO_should_retry(3). BIO_get_retry_reason() IMHO does NOT return a mask of the cause of a retry condition, but BIO_retry_type() does. Index: BIO_should_retry.pod === RCS file:

Re: [openssl.org #2006] [PATCH]: Do not use multiple DTLS records for a single user message

Alright. Sounds good. Thanks. I checked the new version of the patch and I do endorse it. Just in case anybody is wondering why the patch removes the following code segment: /* next chunk of data should get another prepended empty fragment * in ciphersuites with known-IV weakness: */

Re: [openssl.org #1984] [PATCH]: DTLS: ssl3_read_n() concatenates UDP datagrams in DTLS case

Dear Michael, I've got some concerns regarding your patch: Michael Tuexen via RT wrote: I have looked at the patch provided by Daniel. All suggested changes are OK, but there are two additional things which should be fixed: 1. In ssl3_read_n() the argument max is overwritten before used. I

[openssl.org #1984] [PATCH]: DTLS: ssl3_read_n() concatenates UDP datagrams in DTLS case

ssl3_read_n() was conceived to read blocks of data from a byte oriented stream. This can be easily explained by an example: You call ssl3_read_n() with the a parameter like Read 50 bytes of data. As opposed to the read() function provided by the OS, ssl3_read_n() makes sure you really get 50

[openssl.org #1962] [PATCH] dtls1_get_record() returns a bad record in one edge case

dtls1_read_bytes() uses dtls1_get_record() to get a record from the wire. There's an agreement between those two functions that says that ssl-s3-rrec.length contains the length of the record just read. If ssl-s3-rrec.length equals 0 then there's no record in the buffer. dtls1_get_record()

[openssl.org #1923] dtls1_retrieve_buffered_fragment: Read from freed data structure

This is a bug report. Version: openssl-1.0.0-beta2 OS: Ubuntu 9.04, Linux 2.6.28-11-generic #42-Ubuntu SMP When I run ./openssl s_server -dtls1 -no_ecdhe -timeout -cert large.pem against ./openssl s_client -dtls1 I'll get a Segmentation fault on the client side. I attached the certificate

[openssl.org #1921] DTLS: openssl s_client broken in 1.0.0-beta2 due to lack of ECDHE support

Bug report. openssl-1.0.0-beta2 uname -a Linux daniel-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux OS: Ubuntu 9.04 I built a vanilla openssl-1.0.0-beta2 on a and tried to run ./openssl s_client -dtls1 against ./openssl s_server -dtls1 To my