Problem solved, right?
Not exactly, as there is a TLS variant called datagram transport layer security (DTLS) that is designed to emulate the behavior of TLS on UDP services, such as VPN tunnels. Fortunately, the standards community is generally on point and came up with a solution in RFC4347 eight years ago that prevents the use of DTLS in DDoS attacks.
As UDP is stateless, is it not possible to establish a session with the service using DTLS, so the protocol must validate the source of the ClientHello request. This is accomplished by transmitting HelloVerifyRequest back to the client, which includes a cookie. Before the client can receive the ServerHello message it must resend ClientHello with the same cookie, giving DTLS a higher degree of assurance that the message actually came from its declared source and was not spoofed.
In other words, the client must prove its identity before it can receive large amounts of data from the server. This DDoS protection not only prevents amplification attacks, but ensures the server is not overloaded by sending resource-intensive certificate responses to illegitimate users.
What if the stateless cookie defense were bypassed?
As we have seen this week, nothing is guaranteed to be secure or foolproof. What if an attacker found a way to bypass the stateless cookie defense? This seems unlikely. However, if it were to occur, there are two other conditions that would limit the damage of a DTLS reflection attack:
1. By design, DTLS closely resembles TLS, which is designed for TCP. This eliminates the benefits of using UDP for latency sensitive applications as it is essentially emulating a stateful connection. Without the performance benefit of statelessness, developers generally do not find it advantageous to use UDP when TCP would provide greater reliability. This means that DTLS is not nearly as popular as TLS, greatly reducing any opportunity that may exist to use DTLS-protected services in a reflection attack.
2. While it is theoretically possible to transmit a handshake message as large as 16.8 megabytes, typical handshake messages are generally much smaller to the order of several kilobytes. In the packet capture analysis above, this resulted in an amplification factor of only nine times, leaving DNS and NTP reflection substantially more viable for use as DrDoS attack vectors.
So everything is OK, right?
Not exactly. While it is extremely unlikely that Heartbleed or any associated protocol such as TLS or DTLS will be used in DDoS attacks, there are other pressing matters.
First, system administrators need to ensure the actual confirmed threat from Heartbleed is controlled and remediated. Several ethical hackers have recently confirmed that SSL private keys can be stolen using the TLS heartbeat vulnerability, contrary to the initial assumptions of experts at companies such as Google, Symantec and CloudFlare.