As already mentioned in this chapter, three different DoS tools are selected to measure the effectiveness of the DoS attack on the given Apache SSL server. These three different tools are based on three different strategies of the DoS attacks. This section explains the working of the these DoS tools along with the strategies they use.
8.2.1 thc-ssl-dos tool
The working of this tool is already explained in Chapter 4. Therefore, details of this tool are not given again in this chapter. This tool exploits the SSL renegotiation feature in the SSL protocols. This tool is considered in this experiment because no one has practically evaluated this tool1. There are few articles providing the theoretical analysis of the impact of this tool. One of the theoretical analysis can be found at [42]. This experiment is an attempt to provide the practical impact of this tool and determine the effectiveness in comparison with the other attack strategies.
8.2.2 sslsqueeze tool
This tool is written by Michal Trojnara [18] and has been released under GNU general Public licence. It uses libevent2 library2. This tool does not perform any cryptographic operations
1
At least not till the time of performing this experiment
2The libevent is an even notification library which provides the mechanism to execute a callback function
8.2 DoS tools and attack strategies 77
such as RSA encryption or decryption, calculating MACs etc. This tool makes use of libevent library for handling the events such as writing bytes to the server at right time and reading server’s response whenever necessary. This tool does not need to use threads to perform complex and lengthy SSL related operation.
In the SSL handshake protocol, RSA decryption is the most expensive operation to per- form. It is performed by the server to obtain the pre-master secret sent by the client. The pre-master secret is encrypted by the client with the server’s public key. An attacker can send number of such decryption requests to the server through SSL handshake to computationally overload the server. But, to achieve this, the client needs to perform the RSA encryption which is not as expensive as RSA decryption but adds to the computational overhead on the client side. There are several strategies to avoid this overhead on the client side. One traditional strategy is to calculate the client key exchange message only once and replay it whenever necessary. The another strategy could be to send just the bogus data to the server instead of encrypted client key exchange message. The server is not going to detect such data as bogus before the decryption. This idea is also quoted at [42]. Once the server completes the decryption of the bogus data and understands that the data decrypted is not a valid key exchange message containing the pre-master secret, the harm (Computational overhead) is already done and hence the purpose of overlading the server with the RSA decryption (cryptographically expensive) is achieved. However, the bogus data should be constructed in such a way that it follows the standard RSA requirements such as in order to make the server decrypt the data, it(client key exchange message) cannot be greater than the length of the modulus of the server’s RSA key pair. OpenSSL checks this condition before decryption. The sslsqueeze tool utilizes the second strategy from the above description. That is, it does not calculates the valid client key exchange message even once. However, it makes sure that the length of this message is according to what SSL server expects before staring the decryption. This is the additive value of the sslsqueeze tool.
In the sslsqueeze tool, the necessary (SSL) handshake messages are prepared initially before starting the attack. These messages are the Client Hello, the client key exchange, the change cipher spec message and the finished message. These message are formatted according to the SSL specification with the correct record header and record body format. The Client Hello message is filled with the Client Hello header and the message body. The client key exchange message is constructed according to the length of the RSA key size. It is required to know the RSA key length in advanced. The target server’s key length can be easily obtained using the OpenSSL s_client command. This is explained in the Appendix B in Section B.3. The change cipher spec message is a message of length 1 byte having value 1. The finished message in this tool is a structure containing a random data. When server receives the client key exchange message and when it finds that client key exchange message is not correctly formatted, the server will disconnect the connection. However, for the sake of following the protocol, this tool sends the change cipher spec message and finished message in the correct order.
The tool starts with creating a new socket. This socket is used to write the first record structure containing the Client Hello message. The server response is read on this connection. Once the server hello message is confirmed to be received, it continues with sending the rest of the prepared message starting with client key exchange message followed by the change cipher spec message and finished message in a single record. The parsing of the data is necessary. Because sending the handshake messages randomly can result in connection termination from the server side. The server does not expect any data from the client until it sends its reply to the first message. In this case, the server does not expect any SSL handshake message after Client Hello is received and before it sends the server hello message in response to the Client
Hello message.
This SSL communication always results in the server issuing the fatal error since the decrypted data at the server side is not well formatted and is discovered by the server after each decryption process. But, this tool does not care about it since the only aim is to make server decrypt more and more data. In this way, the attack continues till the time either server blocks the attacker’s IP or the attacker stops the attack.
8.2.3 BFC (Brute Force with Crypto) tool
In response to the study done in this research and the attack strategies considered up till now, a new and simple DoS tool was constructed. This tool is based on the simple approach. This tool only creates a continuous and parallel SSL connections (with the target server). The concurrency of this tool can be adjusted programmatically. The main objective behind constructing this tool was to compare and analyse the effect of parallel SSL connections with the target server when the standard SSL protocol is followed and all the cryptography needed to be used is used to connect to the server unlike the sslsqueeze tool described in the previous section. The structure of this tool and logic of processing is inspired from number of hacking tools available on the internet. The main characteristics of this tool are as follows:
• This tool uses cryptography and OpenSSL SSL library to implement SSL protocol.
• To connect to the server, this tool uses standard SSL_connect(SSL *s) function so as to initiate the SSL handshake protocol.
• The scalability of the tool is achieved using threads. The scalability refers to the capacity to create simultaneous and continuous SSL connections.
• This tool can produce number of parallel connections to the server from the single computer.
This tool is nothing but the program which continuously opens the SSL connection with the target server to be attacked. This tool starts with creating the number of connection ends (Connection ends refer to the number of virtual machines to create the SSL connections). This number can be easily adjusted by the user of the tool. This number signifies the number of SSL connections that will be possible to create simultaneously. Of course, this number cannot be set to infinite due to the limitation of the OS to create number of simultaneous sockets. Once the connection ends are created, the SSL handshake with the server are started. After completion of the SSL handshake, a proper shutdown is not done that is usually done by callingSSL_shutdown(SSL *ssl). Instead, the SSL object (SSL *ssl) along with the SSL context object (SSL_CTX *ctx) are removed from the cache memory (memory deallocation process). This ensures that the SSL session is not kept in the cache. Hence at the next iteration of SSL connection, the SSL connection resumption3 is avoided and full handshakes is performed. This is required since the expensive operations such as RSA decryption are not done during the SSL session resumption process.
Therefore, this tool uses cryptography throughout the attack and follows the SSL protocol by using the standard OpenSSL [8] SSL library function calls. Comparing the results of impact of this tool with the impact of the other tools mentioned in this chapter will create a clear picture of the effectiveness of the given strategies to deploy the DoS attack and its effectiveness. It is also important to measure the resources required to perform these attacks on the attacker’s side. It is important that the attacker requires the lesser resources than the server for the attack to be efficient.
3SSL connection resumption is a process of abbreviated SSL handshake and does not involve the RSA