Hi, During a DTLS handshake, the dtls1_buffer_message() function is called in the following order. The values of epoch and handshake_write_sequence are provided.
send_client_hello: epoch==0, handshake_write_sequence==0 send_client_key_xchg: epoch==0, handshake_write_sequence==1 send_change_cipher_spec: epoch==1, handshake_write_sequence==2 send_finish: epoch==1, handshake_write_sequence==2 The latter two have the same epoch and sequence number, because the dtls1_send_change_cipher_spec() function does not increment next_handshake_write_sequence. When send_finish calls, line 1009 of d1_both.c (0.9.8k) creates a pitem that has the SAME priority value as the pitem for the change_cipher_spec message. In most cases, the CCS message is still in the queue when send_finish is added. pqueue does NOT allow duplicate priority, so line 1023 will not queue the send_finish message. This error condition is not handled, which causes a memory leak of the pitem and the send_finish message. I have a few more observations related to this bug: 1) RFC4347 section 4.1, last but one paragraph states, "As with TLS, the sequence number is set to zero after each ChangeCipherSpec message is sent." This is not done in the code. Only the epoch is incremented. 2) Line 1007 of d1_lib.c (0.9.8k) only uses the low-32-bit of seq64 with the epoch placed in bit 16-31. The correct implementation should place the epoch in high-16-bit and the sequence in low-48-bit according to RFC4347 section 4.1. 3) In line 1082 of d1_srvr.c (0.9.8k), handshake_write_seq is incremented independent of next_handshake_write_seq. A similar piece of code can be seen in line 978 of d1_clnt.c, but it was commented out. Both seem questionable, because the handshake_write_seq should get its new value from next_handshake_write_seq. Thanks --Michael ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
