of the overall mitigation techniques based on the observations made during this research is given in next section.
Attributes Attack Strategies
SSL renegotiation Brute force attack Brute force attack
based with cryptography without cryptography
[thc-ssl-dos] [BFC] [sslsqueeze]
Load on server High Medium Low
SSL renegotiation Required Not required Not required support
Cryptography support Required Required Required Computational requirement High High High
at server side (Impact on the processor)
Mitigation Easy Hard Hard
Table 10.5: Applicability of DoS attack strategies on different versions of the SSL protocols
10.3
DoS Attack Mitigation Techniques
This section is dedicated to provide some mitigation techniques for DoS attacks on the SSL protocol.
Since the significant overhead on the SSL server is due to the expensive cryptographic operations performed during the SSL handshake protocol, the rate of SSL handshake should be reduced at the first place. This can be done by using the session cache technique. Using the abbreviated handshakes (SSL session resumption), expensive cryptographic operations are not performed.
10.3.1 Mitigation by monitoring
• Detect the sources that send an excessive number of requests for a secured object. Automated attack tools almost always request web pages (or any other resources) more rapidly than standard users. The SSL connections that are terminated continuously just after RSA decryption are most probably DoS attack traffic. Therefore, monitoring and blocking such connection requests can mitigate the SSL DoS attack those are based on gratuitous requests to create the computational burden on the server. However, there is no explicit mechanism (at least in OpenSSL) to detect whether RSA decryption is successful. Still monitoring the SSL error messages can be useful to employ such mitigation technique.
• The sources that requests for some standard and small pages such as index pages and issues the SSL renegotiation request in an excessive number is likely to be the sign of the DoS attack. This would be the SSL renegotiation based resource exhaustion attack. Monitoring and blocking such traffic can be useful in mitigating such DoS attacks. one of such mitigation techniques is already described in Chapter 4.
• The SSL traffic that connects to the server and requests smaller resources at some interval of time repeatedly to keep the connection SSL connection alive can be a part of the SSL DoS attack where an attacker tries to engage the server in an idle connection and slowly depleting the server’s capacity to serve new SSL connections. Such requests should be monitored and phased out.
10.3.2 Mitigation by load balancing and abbreviated handshakes
• Load balancers (especially layer 7 load balancers) should be configured in such a way that all the requests from the same source IP addresses are directed to the same servers. This will minimize the need of performing full length handshakes each time and hence will save the net CPU time of the servers belonging to an organization provided session cache are maintained at the server. In addition, the server throughput will increase due to fewer handshakes, enhancing the user experience in terms of short response time.
• Efficient use of session cache will enable the frequent use of abbreviated handshakes. If the user re-visits the web site within a short duration, the session ID included in its client hello message can be used to resume the session remembered by the server in its session cache. It is assumed that the user (browser used by the user) properly includes the session ID in the client hello message.
10.3.3 Mitigation by strategic changes
This section describes some mitigation techniques that involves either the change in protocol or the change in the way SSL protocol can be implemented.
• The client certificates can be used to execute the DoS attack as discussed in Chap- ter 7. Whenever the client certificates are used, the client has to send the client certificatemessage, and thecertificate verifymessage. Thecertificate verify
message is the signedhandshake messages exchanged so far in the current SSL commu- nication. This signature operation is not cheap. Therefore, the client can send a fake
certificate verifymessage to the server in order to save some time and computa- tional power. The OpenSSL server implementation first verifies the certificate chain and then verifies thecertificate verifymessage. Whenever, a single client certificate is used, there is no problem since, the server will have to perform at least one signature verification operation. But, whenever multiple client certificates are used (certificate chain), the OpenSSL can opt to verify the certificate verify message first. If the verification is successful, then it can continue with the process of constructing and ver- ifying the client certificate chain. One important thing is that the server performs the RSA private key decryption (decryption of theclient key exchangemessage) before verifying thecertificate verify message. The operation of decryption is expensive and should not be performed if certificate verify message can not be successfully verified. This is also because, thecertificatemessage can be stolen easily by sniffing the network traffic and hence can be mis-used by the attacker4. But, thecertificate verify message cannot be faked since to prepare the certificate verify message, private key of the certificate is required. This mitigation technique5 is also listed by Vincent Bernat [7].
• Number of literatures, including [63], provides the number of SSL protocol amendments. These literatures are already discussed in this thesis. Such changes in the SSL protocol can be activated when the server is experiencing the load. For instance, if the load on the server is increased beyond a threshold, the server can compulsorily request the clients to solve the computationally expensive problems in order to maintain the server’s availability during the high load conditions. This can reduce the server’s throughput for the legitimate users. However, reduced throughput is better than the total outage. As soon as the load on the server is reduced below the threshold level the SSL server
4The
certificatemessage is sent in the plain-text format.
5