caddozzo: a variant of THC-SSL-DOS attack working against TLSv1.2 without client-initiated SSL renegotation support

In 2011 the hacking group THC released a tool exploiting a peculiar feature of RSA cryptosystem that could case a denial-of-service condition against any TLS service. The attack worked in this way:

    • An attacker establishes a TCP connection with a server and try go through
      the SSL/TLS handshake by sending a Client Hello message. This one is intended to negotiate a ciphersuite where RSA is used both for authentication purpose and as a key exchange mechanism (for instances a suitable one is TLS_RSA_WITH_AES_256_CBC_SHA).
    • If that ciphersuite is supported, server sends back a Server Hello message. It also sends a Server Certificate message (including the server certificate along with its public key) and a Server Hello Done message, giving back the “ball” to client with such a latter message.
    • At this point the attacker generates a premastersecret value, encrypts it with the server public key and sends everything to server.

Now, the client encrypts like so:

M^e mod n

where ^ means power of, M is the premastersecret value needing to be encrypted and e is a small number such as 65537.

The decryption operation on server side is instead performed like this:

C^d mod n

where: ^ still means power of, C is the encrypted value sent by client and d is a very large number (in the context of RSA we call d the private key or simply the private exponent).

Just to give you an idea about how large d can be, with an RSA 2048 bit long
sample private key here is how the decryption operation looks like with d in red:

It’s a number with more than 600 figures!

For additional details about RSA you can look at one of my old whitepaper (section 3.2).

Compared to the exponent used by client (the integer 65537), the RSA decryption operation on server-side is a lot more expensive and CPU intensive task than encryption on client-side.

Moreover (and this is also a fact the THC tool take profit of) there is no need for an attacker to encrypt something (consuming its own resources) with the server public key. He/she can just pick up a random blob of data, attach it to Client Key Exchange message and send everything straight away to server that always will try to decrypt the received blob.

The bottom line is that an attacker with a single machine can challenge a big TLS server causing it to consume 100% of CPU as long as the attacker performs hundreds of TLS handshakes per second.

The video below reproduces the effect of thc-ssl-dos tool when a Postfix mail service supporting SSL is targeted. The attack ends up to be amplified because server is also supporting client-initiated SSL renegotation in this case. So with a single connection, the attacker can establish infinite SSL handshakes:

Now back to 2017. From an attacker standpoint, two are the main obstacles nowadays making the THC SSL-DoS attack ineffective. The first one is thatĀ  SSL client-initiated renegotation is disabled by default on most services and daemons (i.e. Apache web server or nginx) and usually can be disabled on all the others.

For example the video below demonstrates that thc-ssl-dos tool stops to run once SSL renegotation is detected as not supported on target host. The targeted service was Apache web server.

Secondly, the usage of RSA both as authentication and key exchange algorithm does not allow Perfect Forward Secrecy and this is the reason why this configuration is getting less widespread.

However, years ago i discovered another vector of denial-of-service never seen discussed on internet security forums/mailing lists. That’s why i do it now. One of the things i focused my attention on was that the private exponent “d” is not just used during an RSA decryption operation but also with a signing operation, namely when a digital signature is generated. That signature is conversely verified with the public key of server.

$ openssl speed rsa

sign verify sign/s verify/s
rsa 512 bits 0.000085s 0.000006s 11790.7 162333.1
rsa 1024 bits 0.000233s 0.000015s 4295.1 66184.0
rsa 2048 bits 0.001628s 0.000047s 614.3 21101.1
rsa 3072 bits 0.004862s 0.000100s 205.7 10036.1
rsa 4096 bits 0.010956s 0.000172s 91.3 5798.8

By observing the test i run on one of my old laptops is easy to spot how the signing operation is more CPU intensive and computanionally expensive (for a 2048 bit long RSA key by a factor of at least 35x) than the verification process.

The question I asked myself was: is there a way to force a TLS server to embed a digital signature somewhere during the TLS handshake? Yes there isĀ  and it takes less packets sent by attacker compared to THC attack to start consuming CPU server resources.

  1. The attacker sends a Client Hello message by negotiating only Perfect
    Forward Secrecy ciphersuites (for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384).
  2. If that ciphersuite is supported, server sends back a Server Hello message. It also sends a Server Certificate message (including the server certificate along with its public key) and a Server Key Exchange message by embedding a digital signature there!
  3. At this point the attacker sends a TCP reset to close the connection and repeat the step 1.

Compared to THC-SSL-DoS tool, the overhead here for each iteration is the TCP three way handshake that has to be established at the beginning and the TCP RST packet that has to be sent at the end. This costs 4 more small packets multiplied by the number of total established connections, but such a cost is counterbalanced by the fact that the attack can be even carried out on services enabling TLS 1.2 which do not support client initiated SSL renegotation.

I created a tool called “caddozzo” (name credited to prof. Giuseppe Tiralongo) to test my assumption and below you can see that it works either targeting a TLS service supporting or not supporting client initiated SSL renegotation such as Postfix and Apache web server.

Caddozzo is not yet available to the general public at the moment. Tests on SSL accelerators and load balancers are still pending…