In the attached pcap, the first five packets represent a complete DTLS handshake, (the client-side app is using OpenSSL 1.0.0d against a Cisco ASA server). However, packets 6 and 7 appear to be retranmissions, (from the client-side), of the Change Cipher Spec and Handshake records contained in packet 5. The server doesn't know what to make of these, as the handshake is complete from the server's perspective, (in fact, encrypted traffic is happily passing between the two ends before the retransmission -- this is omitted from the pcap).
After looking at the code, it appears that the logic that handles SSL3_ST_CW_FINISHED_A and SSL3_ST_CW_FINISHED_B in dtls1_connect() is calling dtls1_start_timer() when it should presumably be calling dtls1_stop_timer(). The attached patch addresses this issue -- assuming this is indeed the full extent of the problem, (the fix works fine for my specific test setup). Regards, John Fitzgibbon
In the attached pcap, the first five packets represent a complete DTLS handshake, (the client-side app is using OpenSSL 1.0.0d against a Cisco ASA server). However, packets 6 and 7 appear to be retranmissions, (from the client-side), of the Change Cipher Spec and Handshake records contained in packet 5. The server doesn't know what to make of these, as the handshake is complete from the server's perspective, (in fact, encrypted traffic is happily passing between the two ends before the retransmission -- this is omitted from the pcap).
After looking at the code, it appears that the logic that handles SSL3_ST_CW_FINISHED_A and SSL3_ST_CW_FINISHED_B in dtls1_connect() is calling dtls1_start_timer() when it should presumably be calling dtls1_stop_timer(). The attached patch addresses this issue --
assuming this is indeed the full extent of the problem, (the fix works fine for my specific test setup).
Regards,
John Fitzgibbon
dtls-bug.patch
Description: Binary data
dtls-bug.pcap
Description: Binary data
