Record processing

Several experiments were performed to investigate how the SSL records are processed in the SSL protocol. It has been found that the SSL record layer addresses fairly standard problems of DoS attacks that are possible on transport layer protocols such as TCP. However, some of the DoS attacks such as TCP SYN flood, are still possible on the web-servers that uses SSL protocols. This DoS attack is not on the SSL protocols but on the TCP. These attacks will always be possible since SSL runs on the top of TCP. It uses TCP for reliable delivery of the SSL-related data.

10.1.3 Compression in SSL

The SSL enables the use of the compression. The compression method is negotiated along with the cipher suite renegotiation. The client and the server are mandatory to support the

compressionMethod.null compression method. This method indicates that no compres- sion will be used in the SSL communication. In reality, only Google chrome browser sup- ports the compression. Few standard web sites such as www.google.com, www.amazon.com, www.twitter.com does opt for the compressionMethod.null method. Hence it can be con- cluded that these web sites do not support SSL compression. Compression is very much useful when there is a larger amount of content (specially text files) that needs to be transmitted. Most of the e-commerce web sites and internet banking applications involve a very little in- formation (credit card number, passwords, personal information) that needs be compressed. This could also be one of the reasons for the web sites not enabling the SSL compression.

Compression burst handling

Experiment. Send a maliciously crafted SSL record such that when it is in compressed format, it follows the boundary limit imposed by the SSL specification, but when decompressed, it expands into a large amount of data that is not allowed by the SSL specification and/or the SSL implementation cannot handle it.

A theoretical experiment is done to verify whether the server handles the compressed data safely without introducing any vulnerability to produce any memory-related attacks such as buffer overflow. The OpenSSL systematically checks the message boundary before starting decompression to confirm that it follows the limits on the compressed data boundary required by the standard. The OpenSSL also makes sure that the compressed data does not expand into larger size so as to occupy unnecessary memory available to the server. If the compressed data crosses the limit specified by the SSL standard, the process is immediately stopped and it results in SSL connection termination.

Due to the fact that, the compression requires to maintain the history at the both sides of communication. Therefore, in order to produce a compression overhead at the server side, the client will also have to invest significant amount of resources. But, this cost of compression on the client side can be easily alleviated by compressing the data in advanced using the compression history from earlier sessions.

It would be quite interesting to measure the difference (if any) in the overhead at the client side and the server side when compression is used at SSL level. Due to lack of time, the practical results could not be generated to provide the evidence of this issue and measure the impact of SSL compression on the server side.

10.1 Attack Vectors 103

10.1.4 Cryptographic operations

The cryptographic operations are one of the important attack vectors when DoS attacks on the SSL protocols are considered. As discussed in this thesis, the SSL protocols involves the number of expensive cryptographic operations. Especially, the server has to perform the RSA private key operations which are expensive due to several factors discussed throughout in this thesis.

This section summarizes the problems that may lead to DoS attacks with substantial performance impact.

Role of key lengths

It has been found that the usage of long private keys degrades the server’s performance significantly. The experimental results obtained in Chapter 6 are summarized here.

SSL connectionTime required for key lengths (bits) Percentage change for time required between

side 1024 2048 4096 1024 & 2048 1024&4096 1024 & 4096

Server 4.88 12.21 58.70 150.20 380.75 1102.86 Client 2.12 2.33 3.10 9.91 33.05 46.23

Table 10.2: Comparison of time required by the server & the client to perform 1000 hand- shakes for different RSA private key sizes

It is observed that the CPU time requirement of the server increases exponentially with an increase in private key size. Therefore, the selection of the private key sizes should be done carefully. It should be noted that the statistics provided in Table 10.2 is done for RSA key exchange method. One of the important observations from this table is even if the computational overhead on the server is increasing exponentially on the server side, the increase in the overhead on the client side remains significantly lower. However, the server is likely to be equipped with greater processing power compared to the client. But, the server will also have to serve a multiple number of clients.

Therefore, the increased key lengths can impact the server’s performance drastically. This vector can play an important role in executing the DoS attacks on the SSL server.

Role of authentication method and key exchange method

Key exchange method The Diffie-Hellman key exchange method requires both the server and client to perform the exponentiation operation. However, the server can perform its exponentiation operation prior to starting the handshake and hence it requires less CPU time than the client as already shown in Chapter 6.

The RSA key exchange method involves the cheaper public key encryption operation at the client side and the expensive private key decryption operation at the server side increasing the work overhead on the server side. The difference in overhead is already described in this thesis.

Authentication method According to one of the empirical studies in [47], a majority of the web sites uses the RSA certificates for authentication. Alternatively, the DSA certificates may also be used. The DSA signature scheme is balanced unlike the RSA signature scheme. In addition, DSA signature verification requires more time than the DSA signature generation. Therefore, the client is likely to require greater time than the server, as the client verifies the server’s DSA certificate (containing DSA signature).

However, the usage of the DSA certificates are rare. This could be because of the flexibility and ease provided by the RSA certificates. The RSA certificates can play the dual role as the authentication method as well as the key exchange method. Where as in the case DSA method, it can be used only for the authentication and not for the key exchange. For key exchange, a separate method such as DH needs to be used. This will result in an increased complexity.

Distribution of work overhead

One of the important reasons for the SSL to be the target of the DoS attacks is the unbalanced work overhead. The server is the one who has to perform the RSA decryption operation as opposed to the client who performs the comparatively cheaper operation such as RSA encryption.

The other operations involved in the SSL protocol are same on the both connection ends and therefore, do not contribute to the uneven distribution of the work overhead. These operations include the MAC calculation, master secret generation, etc. Once, the SSL hand- shake is completed, the symmetric key operations are very much cheaper than the public-key operations performed during handshake and these operations need to be performed on the both sides.

10.1.5 SSL renegotiation

The SSL renegotiation feature is present in the SSL to enable the renegotiation of the key materials and/or re-authentication of the end-entity. The applications of the renegotiation are described in Chapter 4. On one hand it enables the flexibility in renegotiating a new session, and on the other hand, it introduces the complexity in the already existing SSL protocol.

The SSL renegotiation is one of the important attack vectors that can be exploited to build a hazardous DoS attack. The renegotiation feature can be exploited to initiate the number of SSL handshake protocol. The handshake protocol is itself an expensive part of the SSL protocol. In renegotiation, this fact can be completely exploited to deplete server’s resources such as CPU power. The results in Chapter 8 confirm the harmful impact of renegotiation based DoS attack over the other traditional flood attacks.

10.2

Attack Strategies

This section summarizes the impact of the three DoS tools considered and compared in this thesis. These three DoS tools work on three different attack strategies. These three strategies focus on requesting the server to perform as many handshakes as possible. The difference is the way they request the server to perform the SSL handshake.

10.2.1 sslsqueeze tool

The sslsqueeze tool [18] does not use any cryptography to produce the number of SSL hand- shakes with the server. All the standard SSL Handshake protocol messages and Change Cipher Spec messages are prepared in advanced (in raw hex format). This tool requires tar- get IP address, port number (on which the SSL server is running on the target server) and the key size of the target server. The key size is required in order to construct the client key exchange message of appropriate size according to the target’s key size. This is required since, an implementation such as Openssl [8] verifies the size of the client key exchange message before starting the decryption process.

10.2 Attack Strategies 105

Once, this tool is started, it opens a new socket and starts the SSL Handshake protocol by sending client hello message. When some message is available to read, it is read from the socket to understand the server’s response. It is necessary to understand the server’s response. Once server replies with the server hello, this tool sends the rest of the messages in the SSL handshake protocol.

Problem with sslsqueeze tool

It is observed that the sslsqueeze tool does not perform better than the other two tools discussed in Chapter 8. The main reason behind this anomaly is that sslsqueeze tool does not complete the total SSL handshake with the server. This is because, this tool does not compute the valid key exchange message and it is caught by the server. Therefore, the server terminates the SSL connection immediately. With this scenario, the time required to prepare and transmit the change cipher spec message and the server finished message is absent in transaction spawned by the sslsqueeze tool. In addition, this also saves the server’s effort for one signature and symmetric encryption required to prepare the server finished messages.

These factors impact the performance given by the sslsqueeze tool when compared with other tools. The BFC and thc-ssl-dos tools create the SSL connections with the target server such that these connections are successfully completed before these are terminated either by the server or the control written in the tool itself3.