The SSL renegotiation feature (with and without RenegotiationInfo extension support) in- troduces a different threat to the SSL protocols. This threat is DoS attack. This section explains the DoS threat due to the SSL renegotiation feature along with the proof-of-concept tool calledthc-ssl-dosthat exploits the SSL renegotiation feature to execute the DoS at- tacks on the SSL protocols.
4.2.1 Background
The SSL handshake protocol deals with the expensive operations when compared with the SSL application data protocol. The cryptographic operations performed during the SSL handshake protocol are not symmetric between the server and the client. During the SSL handshake protocol, the server has to perform heavier operations when compared with the client. The cryptographic operations performed during the transmission of the application layer data (the SSL application data protocol) are symmetric between the server and the client. The cryptographic operations in the SSL protocol are described later in Chapter 6.
4.2 The SSL renegotiation based DoS attack tool: thc-ssl-dos 35
The traditional computational DoS attack focuses on initiating a large number of SSL handshake protocol with the server. The idea behind such attack is to force the SSL server to perform a large number of cryptographically expensive operations without performing any significant work at the attacker’s side. This attack intends to deplete the server’s computa- tional resources to disable the server from serving the other legitimate users. The impact of such attack can be easily scaled up using multiple resources that can further open multiple SSL connections with the server.
4.2.2 SSL renegotiation based computational vulnerability
The attack strategy mentioned in this section is a general category of DoS attack where the attacker simply initiates a large number of SSL handshake requests to coerce the SSL server into performing unexpectedly large number of expensive operations. The SSL protocol includes one important feature called SSL renegotiation. The SSL renegotiation is already explained in this chapter. The SSL renegotiation is the process of starting a new handshake in an existing SSL session. The handshake conducted during the renegotiation is protected under existing session state. This means that the renegotiation handshake protocol messages are (mostly) encrypted unless the existing session uses NULL cipher. The normal SSL handshake is conducted in the plain text. This is the only difference between the usual handshake and the handshake carried out during the SSL renegotiation. Intuitively, the SSL renegotiation handshake is as expensive as usual SSL handshake.
In traditional DoS attack as mentioned in this section, the attacker opens a numerous SSL connections with the server to computationally exhaust the server. However, with the help of renegotiation feature in the SSL protocol, the attacker does not have to open many connections to increase the computational overhead on the server. Since, the SSL handshake is the culprit behind the computational overhead, the attacker can simply open a single connection and renegotiate multiple times under the same SSL connection. At the end, motivation behind the attack is to computationally exhaust the SSL server.
4.2.3 Work-flow of thc-ssl-dos tool
The thc-ssl-dos tool originally creates 400 peers 4. The maximum number of allowed peers are 999. However, this maximum number can be easily changed by tweaking the source code. Obviously, the effectiveness of this number depends on several factors such as availability of the bandwidth, the CPU power and OS (Operating System) etc.
The attack starts with the creation of the sockets. The sockets are created in the first step. The TCP connection is established using the file descriptors returned by these sockets. Once the TCP connection is established, OpenSSL APIs (Application Programming Interface) are used to handle SSL-related operations. These operations include the SSL connection establishment and the SSL renegotiation operations under the established SSL connection. The OpenSSL APIs that are used in the thc-ssl-dos tool are described below.
int SSL _connect(SSL *ssl) This API initiates the SSL handshake with the server. The SSL connection is identified by the SSL object passed to this function.
int SSL _renegotiate(SSL *ssl) This API sets the flag for the SSL renegotiation. This API does not performs the SSL renegotiation operation. It only sets the flag that signals the appropriate API (explained below) that the SSL renegotiation can be performed.
int SSL _do _handshake(SSL *ssl) This API performs an the actual SSL handshake. This API is responsible for completion of the entire SSL renegotiation.
4
int SSL _free(SSL *ssl) This API decrements the reference count of the SSL object and removes the respective SSL structure from the cache memory [8].
THC-SSL-DOS tool makes use of a non-blocking I/O. Therefore, one function does not block the functionality of the other function. This implies that the every function used in this tool has to return immediately in spite of its success or failure. It helps in switching control from one function to another and it is performance efficient. The non-blocking I/O increases the scalability of the attack.
The attack starts with creating a single peer to connect to the target server. Peers are dynamically expanded in the program. Whenever a TCP connection is successfully completed for any peer, a new peer is initialized and introduced in the attack. A new peer is introduced in the attack till the time maximum peer limit is not crossed. Once the new peer is introduced in the attack, socket is created for this newly created peer. This socket is used to establish the new TCP connection with the server. On successful establishment of the TCP connection, the SSL connection is established using the standard OpenSSL API SSL _connect(SSL *ssl). Once the SSL connection is established, the server expects the application layer data protected under the negotiated cipher suite. Since the tool is created to attack the server, instead of sending any application layer data, it sends the renegotiation request to the server.
If server sends any data to the peer created through this tool, the data is read from the server and ignored. After every 50 renegotiations, a dummy data is written on the server. The number 50 has no significance. The dummy data is nothing but a byte of value zero. The act of writing something (dummy data) is required to handle a possibility where the server may close the connection from the client (peer = client) if no (application layer) data is sent in the connection for longer time.
The peer is disconnected if one of the following condition occurs.
• If there is a Time Out and a TCP connection cannot be established for a socket. The default time out is set to 10 seconds in this tool.
• If a TCP connection cannot be completed successfully.
• If the server does not support the SSL protocol. This condition is not specific to any single peer. If this condition occurs then thc-ssl-dos tool terminates immediately.
• If the SSL connection fails for some reasons other than the support for the SSL. Some- times the SSL connection cannot be completed if underlying BIO (I/O abstraction) 5 has not completed its operation. An appropriate error condition is handled and appro- priate actions are taken to satisfy the requirements to complete the SSL connection.
• If the SSL renegotiation fails for some reason.
• If SSL renegotiation fails for some unknown reasons then it is concluded that server does not support SSL renegotiation feature. This condition is not specific to any single peer. When this condition occurs, the tool terminates with "SSL renegotiation is not supported" error message. This tool cannot work if renegotiation is not supported at server side.
The peer disconnection process consist of series of operations. Whenever a peer is to be disconnected, the API function SSL _free(SSL *ssl) is called. If the SSL _free(SSL *ssl) is called without calling SSL _shutdown(SSL *ssl) then the session is removed from the session cache. Therefore, whenever a new connection with the same SSL structure is established then the SSL session will not be resumed and complete handshake will take place. After calling SSL _free(SSL *ssl), the file descriptor of the socket is closed.
5
4.2 The SSL renegotiation based DoS attack tool: thc-ssl-dos 37
4.2.4 Impact
Several sources, including the analysis by Eric Rescorla at [42] highlights that the way to measure the impact of computational DoS is by the ratio of the work the attacker has to do, and the server has to do. Greater the ratio more is the impact. In other words, the attack on the server is more effective if the server is made computationally overloaded with lesser computational investment from the attacker’s side. To understand the difference in the traditional computational DoS and renegotiation based DoS, Eric Rescorla has provided a simple theoretical analysis of the computational DoS attack at [42].
The traditional computational DoS is subject to sending three packets to complete the TCP handshake for each new SSL connection. Renegotiation based computational DoS re- quires to perform TCP handshake (three packets) only once at the starting of the attack.
The traditional DoS attack can be constructed in two way. Either perform all the client side cryptography and overload the server with the large number of SSL connection requests or send the canned messages (constructed in advanced). Technically, if the aim of the attack is merely to overload the server with the heavy cryptographic operations, then the attacker has to send only the client hello message and the client key exchange message. This is because the main reason, the server might get computationally overloaded is due to the decryption of the client key exchange message sent by the attacker. In addition, if the client key exchange message is canned and does not contain correct data inside, the server is going to return the fatal error and close the connection after decryption is finished. Therefore, theoretically, sending handshake protocol messages until the client key exchange messages should be sufficient.
It is very important to parse the server hello message before sending the client key ex- change message. This is not considered at [42]. The OpenSSL SSL-server implementation does not expect the client key exchange message as long as (at least) server hello is completely sent. Therefore, it is important to parse the server’s response after sending the client hello message to confirm if the server has sent the server hello message, and it is safe to send the client key exchange message.
The renegotiation based DoS attack needs to follow the complete SSL handshake protocol. Because, in the renegotiation based attack, the attacker needs to maintain the SSL connection with the server. The renegotiation is possible only if the SSL connection exists. The SSL protocol is very sensitive to the inconsistency in the protocol messages. Therefore, if the server expects a specific message, and if it does not receive that particular message, the server terminates the SSL connection issuing the "fatal error" alert. It does not request for the re-transmission of the message. For example, if the size of the encrypted client key exchange messages is not equal to what server expects, it closes the connection. Consequently, the renegotiation based computational DoS attack needs to follow SSL protocol strictly. This adds the extra cryptographic operations and hence the overhead at the attacker’s side. This overhead is not present while conducting traditional DoS attack described in this section.
However, there are number of advantages to the SSL renegotiation based DoS attacks. The need of the separate SSL connections is dramatically reduced. Only one TCP connec- tion needs to be established (three packets) for performing more than one handshake with the server. This increases the effect of the attack with respect to the single machine. The traditional attack is limited by the number of concurrent sockets that can be created and the available bandwidth to scale the attack. As the SSL renegotiation based attack can create the same computational overhead on the server with the lesser sockets, on a given system this at- tack is likely to perform better than the traditional DoS attack. Chapter 8 performs a number of DoS-attack strategy-comparison experiments to confirm these theoretical evaluations.