Return to main page

OpenSSL Bugfix and Feature patches

The files have to be applied in the source folder of the latest releases of OpenSSL (0.9.8x / 1.0.0j / 1.0.1c) with:

patch -p0 < /path/to/patchfile.patch

The following categories are available:



DTLS Bugfixes

Patch OpenSSL 1.0.1-stable OpenSSL 1.0.0-stable OpenSSL
0.9.8-stable
Description
Plain text Tarball Plain text Tarball Plain text Tarball
Cumulative Bugfix Download Download not available not available not available not available This is one patch that includes all of bugfixes but no features. Don't apply the single patches too.
SCTP struct authchunks (#2809) Download Download not available not available not available not available DTLS/SCTP requires DATA and FORWARD-TSN chunks to be protected with SCTP-AUTH. It is checked if this has been activated successfully for the local and remote peer. Due to a bug, however, the gauth_number_of_chunks field of the authchunks struct is missing on FreeBSD, and was therefore not considered in the OpenSSL implementation. This patch sets the corresponding pointer for the check correctly whether or not this bug is present.
SCTP Finished Auth (#2808) Download Download not available not available not available not available With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and FORWARD-TSN chunks. The key for this extension is derived from the master secret and changed with the next ChangeCipherSpec, whenever a new key has been negotiated. The following Finished then already uses the new key. Unfortunately, the ChangeCipherSpec and Finished are part of the same flight as the ClientKeyExchange, which is necessary for the computation of the new secret. Hence, these messages are sent immediately following each other, leaving the server very little time to compute the new secret and pass it to SCTP before the finished arrives. So the Finished is likely to be discarded by SCTP and a retransmission becomes necessary. To prevent this issue, the Finished of the client is still sent with the old key.
Timeout Handling (#2756) included since
1.0.1 release
included since
1.0.1 release
included since
1.0.0h
included since
1.0.0h
included since
0.9.8u
included since
0.9.8u
DTLS does not handle timeouts correctly, because the timeout counter is reset every time anything has been received, and not only after a full handshake flight. The reset should only be done when the retransmission timer is stopped, otherwise the maximum number of retransmission is never met in case a flight always arrives incomplete, so retransmissions continue and the connection is not terminated.
Additionally, the retransmission counter is not increased when the server retransmits its last flight, which is triggered by the retransmission of the client's last flight. This is a problem if the server's last flight exceeds the path MTU, for example. In this case the flight will never arrive at the client, because the server is not counting retransmissions and will not reduce its MTU, or simply give up when the maximum number of retransmissions is reached.
No Lower MTU After Retransmissions (#2755) included since
1.0.1 release
included since
1.0.1 release
included since
1.0.0h
included since
1.0.0h
included since
0.9.8u
included since
0.9.8u
The DTLS implementation does not lower the assumed MTU after unsuccessful retransmissions, which results in a failing handshake in case fragmentation is necessary. With this patch the MTU is reduced to a "safe" value of 576 - 20 - 8 for IPv4 and 1280 - 40 - 8 for IPv6, respectively, after 2 retransmissions.
Possible Timer Deadlock (#2748) included since
1.0.1 release
included since
1.0.1 release
included since
1.0.0h
included since
1.0.0h
included since
0.9.8u
included since
0.9.8u
DTLS maintains timers for every handshake flight in case retransmissions are necessary. In the current implementation the timer is stopped as soon as any message of the following flight arrived. This can lead to a deadlock, if the flight was incomplete for some reason and the missing message is awaited forever with no timer running anymore. This patch changes the timer behavior so that a timer is not stopped until the entire following flight has been received to avoid this issue. This is also required by the DTLS specification.

Thanks to Lindani Phiri for reporting this bug!

Heartbeat Response Padding (#2739) included since
1.0.1 release
included since
1.0.1 release
not available not available not available not available This patch fixes two padding related bugs for the Heartbeat Response messages. For DTLS, the wrong pointer was used, which may overwrite the payload with the random padding. For TLS, there was no random padding at all..
DTLS Timing included since
beta 1
included since
beta 1
included since
1.0.0f
included since
1.0.0f
included since
0.9.8s
included since
0.9.8s
Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can be found at http://www.isg.rhul.ac.uk/~kp/dtls.pdf
ECC Key Signature (#2628) included since
beta 1
included since
beta 1
included since
1.0.0f
included since
1.0.0f
included since
0.9.8s
included since
0.9.8s
The signature in the ServerKeyExchange is created with wrong parameters with ECC keys, because the TLS header length is used instead of the DTLS header length.

Thanks to Erwin Himawan for providing hints!

Fragment Assert (#2625) included since
beta 1
included since
beta 1
included since
1.0.0f
included since
1.0.0f
included since
0.9.8s
included since
0.9.8s
The reception of incomplete or incorrectly formatted DTLS fragments is handled with an OPENSSL_assert(), causing the program to exit rather then just terminating the connection. This patch exchanges the asserts with unexpected message and illegal parameter alerts.

Thanks to Zhu Qun-Ying for reporting this bug!

Manual MTU (#2602) included since
beta 1
included since
beta 1
included since
1.0.0f
included since
1.0.0f
included since
0.9.8s
included since
0.9.8s
Since patch #2506 the MTU stored in DTLS1_STATE is cleared with every initial handshake. This prevents setting an MTU manually when SSL_OP_NO_QUERY_MTU is set and causes OpenSSL to crash because an MTU of 0 is used therefore an memcpy with a negative length in the following. This patch prevents the MTU from being overwritten if SSL_OP_NO_QUERY_MTU is set, adds an assert to prevent invalid MTU values from being used and doesn't allow to manually set too low MTU values.

Thanks to Paul Witty for reporting this bug!

Buffering and Decryption (#2573) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
DTLS buffers records of the next epoch while listening, although it's not supposed to change its state. Additionally, when the decryption of buffered records fails, the connection is dropped with a BadRecord alert, instead of just silently discarding the message. With this patch nothing is buffered while listening and messages that cannot be decrypted will be ignored.

Thanks to Yogesh Chopra for providing hints!

Socket error (#2559) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
The socket timeout is adjusted before reading and reset afterwards, in case a handshake is in progress to handle handshake timeouts properly. The reset, however, is done before the socket error handling. The new system call overwrites the error code when using Windows and breaks the error handling. Doing the error handling first fixes this issue.

Thanks to Nilesh Vaghela for providing hints!

Sequence Numbers (#2555) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
This patch fixes that the server increases the expected handshake sequence number while listening for new connections, although its supposed to not change its state. The server also reflects the record sequence numbers of ClientHellos in its HelloVerifyRequest and ServerHello messages now to remain stateless, as described in http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-06.

Thanks to Yogesh Chopra for providing hints!

HelloVerifyRequest Timer (#2550) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
The server starts a timer when sending a HelloVerifyRequest, although its state should remain unchanged.

Thanks to Yogesh Chopra for finding this bug!

Handle Timeout Errors (#2543) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
DTLSv1_handle_timeout() does not handle errors because of too many retransmissions correctly. The return value should be -1 instead of 0, so the application can detect the error.

Thanks to Nilesh Vaghela for finding this bug!

Release buffers (#2533) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
not available not available Setting SSL_MODE_RELEASE_BUFFERS should be ignored for DTLS, but instead causes the program to crash. This is due to missing version checks and is fixed with this patch.
SSL_Clear() implementation (#2506) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
The implementation of dtls1_clear(), called by SSL_clear(), is not handling the DTLS1_STATE struct at s->d1. Hence, calling SSL_clear() does not reset any value stored in this struct, which includes epochs, sequence numbers, replay check bitmask, buffered messages, etc. This also prevents the -reconnect option for s_client from working, because the state is not fully cleared and thus the next connection attempt starts with an initial ClientHello with epoch 1, which is invalid and ignored by the server. This patch adds clearing all values and emptying all queues in s->d1 when calling SSL_clear().

This patch is updated to also address the memory leak reported in #1714.

Session Resumption Timer (#2505) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
The client always starts timer for the retransmission of the ChangeCipherSpec and Finished, although that is only correct when performing a full handshake. With the abbreviated session resumption handshake, these messages are not followed by a response of the server, so the timer is never stopped and causes retransmissions until the connection is dropped. This patch adds the distinction between full and abbreviated handshakes and prevents the timer from being started in the latter case.

Retransmission buffer (#2462) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
DTLS clears the handshake retransmission buffer every time a message has been received, assuming no retransmissions are necessary anymore. This fails when the last flight of the server was lost twice. The first time DTLS bundles the SessionTicket, ChangeCipherSpec and Finished messages into one packet. If this gets lost, the client repeats its last flight. The server will then retransmit the mentioned messages each in a single packet. If any of them is lost again, the flight is not complete but the client clears its retransmission buffer as soon as the first message of the flight arrives. The server assumes that the handshake has been completed but the client still awaits a retransmission of the last flight. The client retransmits its empty buffer, that is nothing, and will give up when it reached its max number of timeouts. This can be solved easily by clearing the buffer when the retransmission timer is stopped. That happens when nothing has to be retransmitted anymore which is exactly when the buffer is supposed to be cleared.

Thanks to Robert Story for providing hints!

State changed while listening (#2458) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
While listening for incoming connections, DTLS should answer every ClientHello with a HelloVerifyRequest without changing its state. However, this is not the case since the handshake sequence numbers are still incremented with every incoming message. After receiving an initial ClientHello (seq 0), seq 1 is expected (ClientHello with cookie) and every other initial ClientHello will be dropped until seq 1 has been received. This may even result in an infinite loop when the expected sequence number becomes > 1 due to a race condition with many simultaneously connecting clients, because the expected number will never appear while in listening state. The changes of the attached patch prevent the increase of the sequence numbers while listening, so only sequence number 0 (initial ClientHello) will be expected and accepted. An exception exists for sequence number 1 (ClientHello with cookie), which has to be allowed as well. After a valid ClientHello with cookie has been received, the sequence numbers are set to the expected values to continue the handshake. Additionally, HelloVerifyRequest messages aren't buffered and retransmitted anymore, since this would also change the state of the listening server according to RFC 4347.

Thanks to Neeraj Rajgure for providing hints!

Reassembly Bitmask (#2457) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
included since
0.9.8s
included since
0.9.8s
With patch #2230 a DTLS reassembly bitmask array should have been changed. Unfortunately this change was lost, so there is still a bug. Fragmented messages with lengths of multiples of 8 may not be handled correctly, because the highest byte of the bitmask will be compared to 0x00 instead of 0xff.

Reassembly (#2230) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
The reassembly for fragmented DTLS handshake messages only works if the fragments don't overlap, aren't reordered and haven't been retransmitted. This patch fixes this and allows the reassembly of messages regardless of retransmissions, losses, reordering or even the mixture of fragments of different messages. Incomplete messages now have a bitmask to keep track of the fragments and are buffered until completed. This allows the reassembly of fragments in random order and from multiple messages at a time, instead of reassembling only the message currently being processed and dropping everything but the expected fragment.

Also fixed is the issue mentioned in #2221 by Daniel Mentz, that zero length fragments aren't buffered.

MAC validation or decryption failure drops connection (#2229) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
DTLS drops the connection with a BAD_RECORD alert whenever validation of the MAC or decryption failed. This is ok with the specification as an optional behavior but is also an easy target for a potential attack to drop the connection. An attacker only has to send random data to cause the decryption to fail and the connection is closed. So DTLS should rather silently discard those messages and continue the connection.
MAC validation for buffered messages (#2228) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
Whenever handshake messages are buffered because they arrived reordered and already belong to the next epoch, the MAC validation fails when the messages are finally processed because the sequence number is not restored and instead 0 is always used. This is fixed with setting the s->s3->read_sequence variable when retrieving buffered messages.
Timeout Divergences (#2223) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
To handle handshake message timeouts properly, DTLS sets the socket timeouts according to the currently remaining time until the next timeout occurs. However, in some cases this doesn't work because the operating system returns the socket call a few milliseconds before the DTLS timer expires. To solve this, the remaining time until timeout is set to 0 if it is less than 15 ms.

Thanks to Daniel Mentz for finding this bug!

Replay check (#2218) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
The sliding window which keeps track of already received sequence numbers for the replay check should only be updated after the HMAC of a message has been verified. This is not the case when the message is from the next epoch already and therefore has to be buffered. The sequence number is marked as receieved without the HMAC verification, which is not possible yet, making a DOS attack possible. This patch prevents that and also a message from the next epoch is only buffered if a handhake is really in progress.

Thanks to Daniel Mentz for finding this bug!

Buffering Priority (#2219) included since
beta 1
included since
beta 1
included since
1.0.0a
included since
1.0.0a
included since
0.9.8o
included since
0.9.8o
Application data arriving between ChangeCipherSpec and Finished is buffered and processed after the handshake has been completed. While calling dtls1_buffer_record() a NULL-pointer was passed as priority. This causes a crash when multiple messages have to be buffered. With this patch the sequence number of the corresponding record is used as the priority as intended.

Thanks to Daniel Mentz for finding this bug!

SessionTicket Extension (#2160) included since
beta 1
included since
beta 1
included since
1.0.0 release
included since
1.0.0 release
included since
0.9.8m
included since
0.9.8m
The Sessionticket extension doesn't work with DTLS. The NewSessionTicket message of the server is truncated because of a wrong calculation of the length and the server is also unable to parse the ticket attached to a ClientHello because DTLS is considered as an unknown protocol version.
DTLS Extensions (#2121) included since
beta 1
included since
beta 1
included since
beta 5
included since
beta 5
included since
0.9.8m
included since
0.9.8m
Adds the renegotiation (now mandatory for security reasons), servername and session ticket extensions to DTLS.
IPv6 issues (#2110 & #2114) included since
beta 1
included since
beta 1
included since
beta 5
included since
beta 5
not needed not needed Changes IPv6 integration to a more elegant solution and fixes some sockaddr size issues when using IPv4.
MTU Fragment (#2089) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
DTLS fragmentation doesn't consider the additional data required with using encryption, so the packet size then exceeds the MTU when fragmentation is performed. This patch subtracts the size of the mac and the additional encryption bytes of the maximum possible length for a fragment, if necessary.

Thanks to Daniel Mentz for finding this bug!

IPv6 (#2069) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
not available not available This patch adds IPv6 compatibility for DTLS and the s_server/s_client test applications.
Handling of ENOTCONN and EMSGSIZE for dgram bios (#2050) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
This patch fixes the handling of error cases: For dgram bios use always BIO_dgram_should_retry() instead of BIO_scok_should_retry(). ENOTCONN is a fatal error. EMSGSIZE is a fatal error, not related to path MTU.

Thanks to Daniel Mentz, who pointed out the incorrect error handling when testing with the DTLS/SCTP implementation.

Listen (#2039 & #2039) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
This patch adds the function dtls1_listen(SSL *s, struct sockaddr *client), as well as the user accessible macro DTLSv1_listen(). It is intended to be called with an SSL object with a listening socket. Every ClientHello arriving will be answered with a HelloVerifyRequest without allocating any memory. When a ClientHello is repeated with a valid cookie attached, dtls1_listen() returns after entering the peer's address into the given sockaddr structure. The application can then create an UDP socket connected to that peer, assign it to the SSL object and continue the connection (with a SSL_accept() to complete the handshake, since the dtls1_listen returns before sending the ServerHello) in a new thread. Then a new SSL object has to be created and the listening socket has to be assigned to it, so that following connections can be handled.
Cookie Management (#2028) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
This patch fixes several issues with DTLS cookies. At first the maximum cookie length was defined as 32 bytes, while the specification states 256 bytes. Then there was code in the wrong order which prevented the use of cookies larger than 0 bytes in ssl3_get_client_hello(), it was tried to process extensions before the cookie. The present implementation always expects a ClientHello, sends a HelloVerifyRequest and then expects a ClientHello with a cookie attached. Everything else is considered as an error, which is not correct because the first ClientHello could be repeated. Now every ClientHello is answered with a HelloVerifyRequest until a ClientHello with cookie appears. Then the cookie is verified and an error returned if the verification failed. If SSL_OP_COOKIE_EXCHANGE is set, in dtls1_send_hello_verify_request() the cookie is sent. It was assumed that the cookie was specified "somehow" else if the user did not register a callback function for cookie generation. This doesn't make any sense because if the user doesn't use the designated function to generate cookies, how else should they be generated? The result is a cookie with length 0, which is almost as bad as no HelloVerifyRequest at all. Now an internal error occurs if the user requests cookie exchange but did not register the required callback functions. The application s_server activated cookies but didn't supply any generation or verification functions. They are added now and use a 16 byte random number as a secret to calculate an HMAC over the peer's address and port as suggested in the DTLS specification.
Record Header Length (#2022) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
This patch fixes the size of the read and write buffers which are 8 bytes too small for DTLS. The function ssl3_setup_buffers() is called to allocate the necessary memory for the read and write buffers. This is done in two subfunctions, ssl3_setup_read_buffer() and ssl3_setup_write_buffer(). Unfortuanately there is no difference between TLS and DTLS, although both use different record headers with different lengths.
Fragmentation (#2006) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
Fixes a bug where a single user message was fragmented and distributed over multiple DTLS records if its size exceeds the MTU.
Timeout Handling (#1997) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
This patch fixes the timeout handling. The method dtls1_get_timeout() was intended to determine the next handshake message timeout when using select() calls, to set their timeout. This method is now avaiable as DTLSv1_get_timeout(), to fit the common naming scheme. Additionally, the timeout handling is moved to the method dtls1_handle_timeout(), which can be called by the user as DTLSv1_handle_timeout() when a select() timer expires. Until now expired timers were handled not until a SSL_read() is called. This is a problem when using select() on the reading socket, because no call of SSL_read() is done before data from the peer arrived. The test programs s_server and s_client are also modified to make use of the new timeout handling to fully support timeouts.
Cookie Renegotiation (#1993) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
In d1_clnt.c the variables s->d1->send_cookie and s->hit aren't reset when initiating a new renegotiation handshake. This is ok if a new session is created, that is everything will be reset anyway, but with an abbreviated handshake without a new session this causes the handshake to fail. Additionally a typo in d1_pkt.c in OpenSSL 1.0.0 is fixed.
s_server msg (#1991) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
When using s_client and s_server with DTLS and the -msg arg, the message types are not printed. This fixes adds support in the corresponding callback for printing DTLS message types.
Socket Timeout (#1990) included since
beta 1
included since
beta 1
included since
beta 4
included since
beta 4
included since
0.9.8m
included since
0.9.8m
When the socket timeout has to be adjusted because of a handshake timeout expiring earlier, the user set value is saved and reset afterwards. This patch adds a missing if-clause in dgram_reset_rcv_timeout() to prevent the reset of the socket timeout when no timer is active. Since no adjustment has been done then, no previous socket timeout has been saved and the socket timeout will be always set to 0.
Record Header (#1981) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
This patch changes the behavior of DTLS regarding erroneous record headers. The current implementation reports an error if the version or length entries of the record layer are unexpected and closes the connection. This is probably takes over from TLS but doesn't make sense with DTLS, since an attacker can easily send random data to close the connection. In fact every packet not containing the correct version and length terminates the connection. With this patch such packets are just silently discarded to keep the connection alive.
ECDH Renegotiation Bug (#1952) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
Download Download The variable s->s3->tmp.ecdh is set in ssl3_send_server_key_exchange() or dtls1_send_server_key_exchange(), after checking if it points to NULL. Later it is read only once in ssl3_get_client_key_exchange(), but then not freed and set to NULL again. When a renegotiation with a full handshake is performed to compute new key material, the procedure is the same and s->s3->tmp.ecdh should be set in the send_server_key_exchange() functions. This fails because it has not been set to NULL in advance, so no renegotiation is possible, even worse, this causes the connection to fail. This patch adds two lines to free the variable right after it has been used, to allow it to be set again during following renegotiations.
Fragment Retransmission Bug (#1950) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
When handshake messages can't be reassembled because a fragment got lost, the ChangeCipherSpec included in the same flight was still processed. The new mastersecret has not been calculated yet, so random memory is used causing the connection to fail. This patch drops every ChangeCipherSpec which arrives before all previous messages are processed. It doesn't have to be buffered because always the entire flight is repeated, so it will be sent again anyway. This patch also fixes wrong socket timing causing retransmissions to be sent later than necessary. Finally this patch also fixes a problem with stale retransmits of Finished messages of a previous handshake when a new one is initiated. It will be dropped instead of buffered and processed after the ChangeCipherSpec if it arrives before the ServerHello, when it obviously can't belong to the current handshake. Otherwise the connection fails with unexpected message.

Thanks to Daniel Mentz for providing hints!

Record buffer limitation Bug (#1930) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
Records are buffered if they arrive with a future epoch to be processed after finishing the corresponding handshake. There is currently no limitation to this buffer allowing an attacker to perform a DOS attack with sending records with future epochs until there is no memory left. This patch adds the pqueue_size() function to detemine the size of a buffer and limits the record buffer to 100 entries.

Thanks to Daniel Mentz for finding this bug!

MTU Bug (#1929) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
The PMTU discovery was Linux specific but not enclosed with defines if Linux is actually used. This caused problems on other platforms. If the MTU was discovered or set by the user, it was not considered that the IP and UDP header have to be subtracted to get the size available for DTLS. Hence, messages could be up to 28 byte larger than the MTU which causes IP fragmentation or packet loss.

Thanks to Daniel Mentz for finding this bug!

Fragment Memory Leak Bug (#1931) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
In dtls1_process_out_of_seq_message() the check if the current message is already buffered was missing. For every new message was memory allocated, allowing an attacker to perform an denial of service attack with sending out of seq handshake messages until there is no memory left. Additionally every future messege was buffered, even if the sequence number made no sense and would be part of another handshake. So only messages with sequence numbers less than 10 in advance will be buffered.

Thanks to Daniel Mentz for finding this bug!

Fragment Segmentation Fault Bug (#1923) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
In dtls1_retrieve_buffered_fragment() a fragment may be freed before returning its length. This causes a segmentation fault. This is fixed with storing the length in a different variable and returning this one instead of the fragment property which is not available anymore.

Thanks to Daniel Mentz for finding this bug!

Timer Bug (#1829 & #1922 & #1990) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
DTLS has to maintain timers to retransmit lost packets. Until now there is no timer, retransmissions are only performed, when the socket returns an EAGAIN. This also is a problem when using non-blocking sockets. This patch adds timer functionality to the DTLS implementation. A timer is started for every handshake message and this message is repeated if the timer expires. The timer is initialized with 1 second and doubled at each timeout up to 60 seconds, according to the RFC 4347. Whenever the BIO object is about to read from the socket, it is checked if there is a timer running for an expected handshake message. If so, the socket timeout is compared with the remaining time of the timer and adjusted if the message timer expires earlier. For OpenSSL 1.0.0 beta 2 this patch replaces the timer functionality added with #1829, because this was not cleanly implemented and not compatible with non-blocking sockets at all. This patch was updated for 0.9.8 to resolve the issue #1990 of OpenSSL 1.0.0 beta 3.

Thanks to Daniel Mentz for his suggestions!

Fragment Bug (#1838) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
Whenever a handshake message arrives with an unexpected sequence number, it is passed to the function dtls1_process_out_of_seq_message(). This function discards the data if the sequence number is lower than the expected value and buffers it, if is a future message. When discarding, the message fragment length remains 0 which indicates that nothing has to be buffered. Due to a misplaced if condition to check the length, sometimes fragments with no data but with the length of the dropped message are buffered. This causes a bus error when processing later.
Retransmission Bug (#1828) included since
beta 1
included since
beta 1
included since
beta 3
included since
beta 3
included since
0.9.8m
included since
0.9.8m
This patch solves four issues. At first the index of the retransmission queue is the message sequence number bitwise ORed with the current epoch. The epoch cannot be used to retrieve the buffered messages because it could have changed until a retransmission has to be done and is therefor not necessarily known. Since there can only be one handshake at a time, every message can only be once in the queue so the epoch can be removed. The message sequence number alone is not sufficient, because the ChangeCipherSpec doesn't have one, so it will have the same index as the Finished. A solution is using the message sequence number multiplied by 2 and if the message is a ChangeCipherSpec 1 is subtraced. This has the advantage that the index of the CCS is always one less than the Finished, so the order of the indices is preserved, which is important in a priority queue and the unsigned short sequence number variable can be kept. more...
Application Data in Handshake Bug (#1827) included since
beta 1
included since
beta 1
included since
beta 2
included since
beta 2
included since
0.9.8m
included since
0.9.8m
The current DTLS implementation always generates an SSL_R_UNEXPECTED_RECORD error if application data is received while handshaking. This is ok for the first handshake, but not necessary for renegotiations. Furthermore it's likely that the connection fails just because of unordered UDP packets. The DTLS specification does not mention this issue, but there is no reason not to accept belated application data while renegotiating, as long as the key material has not changed yet. With this patch the implementation will leave the handshake routine, return the application data and generate the error SSL_ERROR_WANT_READ, so that the application reads again to continue handshaking.
Client Random Bug (#1826) included since
beta 1
included since
beta 1
included since
beta 2
included since
beta 2
included since
0.9.8m
included since
0.9.8m
Everytime a new handshake is initialized the value s->s3->client_random gets filled with random numbers for the ClientHello. The value has to be reused if the ClientHello has to be repeated because the server sent a HelloVerifyRequest. In the function dtls1_client_hello() is checked if client_random is still zero or already set to decide whether new random numbers have to be generated. In the state SSL3_ST_CW_FINISHED_A the client_random is overwritten with zeros to indicate that the next time a ClientHello is sent new random values have to be generated. This is not only redundant with the memset call at the beginning of the handshake in state SSL_ST_CONNECT, it also prevents to use the value after the handshake is done. So the redundant memset call should be removed. This is important for the TLS key material extractor feature which relies on the client_random value.
Renegotiation Bug (#1647) included since
beta 1
included since
beta 1
included since
beta 2
included since
beta 2
included since
0.9.8m
included since
0.9.8m
As described in bug report #1647 both server and client are hanging when calling SSL_renegotiate() with DTLS. The client sends the ClientHello to the server, but the message sequence number has not been reset to 0 after the first handshake. So the server drops it (out of sync) and continues waiting for the ClientHello while the client is waiting for the server's response. This patch resets the message sequence number to 0 after finishing a handshake.




Features

Patch OpenSSL 1.0.1-stable OpenSSL 1.0.0-stable OpenSSL
0.9.8-stable
Description
Plain text Tarball Plain text Tarball Plain text Tarball
DTLS Mobility (#2869) Download Download not available not available not available not available This patch adds support for DTLS Mobility, as published in our paper:

http://link.springer.com/chapter/10.1007/978-3-642-25959-3_33?null

After negotiating support with HelloExtensions, an extended RecordHeader is used to allow changing IP addresses with an unconnected UDP socket. Address changes are detected and the new address is verified with the Heatbeat protocol. With this extension a DTLS connection can be kept alive on mobile clients, which usually move between cell phone and WiFi networks.
Don't Fragment (#2830) Download Download Download Download Download Download This patch adds the BIO_CTRL_DGRAM_SET_DONT_FRAG option for BIO_ctrl() to activate the Don't Fragment bit for the current socket, if possible on the platform.
Abbreviated Renegotiations (#1833) included since
beta 1
included since
beta 1
not available not available not available not available Whenever a handshake is initiated, the variable s->new_session is set to indicate that a handshake is being performed. This is not the correct context because a handshake can also be abbreviated and will not create a new session then. This variable is also used in the right context to determine whether or not the current Session ID is sent with a ClientHello. The result is that renegotiations always create a new session because the handshake state has to be set. There is no possibility to perform an abbreviated handshake for renegotiation conform to the TLS specification. This patch adds the variable s->renegotiate to indicate handshakes, so that s->new_session only indicates if a new session should be created, that is a full handshake should be performed. The patch also adds the function SSL_renegotiate_abbreviated(SSL* ssl) which can be used to trigger an abbreviated handshake. The functionality of SSL_renegotiate(SSL* ssl) remains the same and always performs a full handshake.
TLS Key Material Exporter (#1830) included since
beta 1
included since
beta 1
not available not available not available not available Adds the TLS key material exporter described in RFC 5705. This feature is mandatory for DTLS for SCTP to extract key material for SCTP-AUTH.
SCTP-aware DTLS (#2535) included since
beta 1
included since
beta 1
not available not available not available not available Adds SCTP support for DTLS as described in RFC 6083.

The new configure option 'sctp' will be added. To compile OpenSSL with SCTP support use './config sctp'.

Heartbeat Extension (#2658) included since
beta 1
included since
beta 1
not available not available not available not available Adds the TLS/DTLS Heartbeat Extension described in RFC 6520.




Generic Bugfixes

Patch OpenSSL 1.0.1-stable OpenSSL 1.0.0-stable OpenSSL
0.9.8-stable
Description
Plain text Tarball Plain text Tarball Plain text Tarball
BIO_new_accept() binds IPv6 only (#2512) included since
beta 1
included since
beta 1
included since
1.0.0e
included since
1.0.0e
not available not available This patch fixes BIO_new_accept() to behave as expected.
BIO_new_accept("8080") will bind an IPv4 or IPv6 socket, which depends on the system.
BIO_new_accept("::8080") will bind an IPv6 socket.
BIO_new_accept("*:8080") will bind an IPv4 socket.
Define OPENSSL_SYS_BSD (#2227) not available not available Download Download not available not available This patch adds an OPENSSL_SYS_BSD define, to consider BSD platforms when implementing platform-dependent functionality. This is necessary for future DTLS features.
FreeBSD Compatibility (#1900) included since
beta 1
included since
beta 1
included since
beta 2
included since
beta 2
Download Download In ssl/kssl.c the constant _XOPEN_SOURCE is defined which results in using an old POSIX version and compilation problems on recent FreeBSD systems when adding SCTP support (necessary for SCTP-aware DTLS). With _XOPEN_SOURCE defined to 500, in sys/cdefs.h the constant _POSIX_C_SOURCE will get the value 199506 instead of 200112. The constant __POSIX_VISIBLE then gets the same value, so an old POSIX version will be assumed. This is not only needless, it also is a problem when including netinet/sctp.h to use SCTP. In this header file the structure sin6 is needed, which is defined in netinet/in6.h that gets included by netinet/in.h, but only when #if __POSIX_VISIBLE >= 200112 is true. Hence, defining _XOPEN_SOURCE to 500 makes it impossible to use SCTP, even if the constant is undefined afterwards. Since there is no use of any funtion of time.h, the corresponding code should just be removed.


If you have any comments please contact seggelmann@fh-muenster.de.