8

When the SSL handshake takes place, is there a point where the computational work done by the client is significantly less than the computational work done by the server?

Could such an imbalance be exploited to produce a DoS with greater efficacy? Are there any academic papers or proof-of-concept implementations of this?

  • It's a really interesting question, though wouldn't a properly configured server deny requests from a hammering server at the IP level effectively rendering the extra attack power void after the first few requests? – Zeta Two Aug 2 '12 at 11:16
  • 1
    @ZetaTwo Sure, but a lot of them aren't properly configured. Plus a large botnet could be quite selective about how often each node sends a request, to make filtering difficult. – Polynomial Aug 2 '12 at 11:27
  • @ZetaTwo What about carrier-wide NAT? IPv6 to IPv4 NAT? – curiousguy Aug 2 '12 at 11:59
  • @curiousguy If that is a question, it is unfortunately beyond my knowledge. =( – Zeta Two Aug 2 '12 at 12:03
6

Yes, a CPU-based DoS on SSL servers is easy. Consider the two main types of cipher suites, as commonly used in SSL:

  • RSA key exchange: server sends its certificate with a RSA public key; client generates a random blob (the pre-master secret key) encrypted with the server's public key; the server decrypts it.

  • DHE key exchange: server sends its half of a Diffie-Hellman key exchange, signed with the server's private key. Client sends its own half of DH. Server completes DH key exchange by applying its DH private key (a modular exponentiation).

Either way, the server must perform a relatively heavy cryptographic operation: an RSA decryption, or a DH modular exponentiation (for DHE, the server can reuse its ephemeral DH parameters, as long as it does not reboot, but it cannot evade the final modular exponentiation computed over what the client sends). On the other hand, a client who tries to DoS the server does not need to do any work at all: it just needs to send a blob of approximately the right size. Decryption on the server will fail, but the CPU expense will be lost nonetheless.

(Already with honest clients and RSA key exchange, the CPU cost is higher in the server, because RSA encryption is much faster than RSA decryption. But an evil client, intent on DoSing, can totally avoid work.)

Such attacks have been observed in the wild and it does not take an academic paper to explain how they work.

1

Yes, there are such points. Especially if SSL-Renegotiation is active, those can be exploited in order to bring down a server quite effectively:

enter image description here

This chart, taken from SSL computational DoS mitigation shows the calculation-time needed to handshake between client and server, using common algorithms. As you can see some algorithms are significantly better than others.

For example, with 2048bit RSA certificates and a cipher suite like AES256-SHA, the server needs 6 times more CPU power than the client. However, if we use DHE-RSA-AES256-SHA instead, the server needs 34% less CPU power. The most efficient cipher suite from the server point of view seems to be something like DHE-DSS-AES256-SHA where the server needs half the power of the client.

For detailed information about this, checkout SSL computational DoS mitigation and the original release notes of the THC-Tool being used to demonstrated this dDoS: THC SSL DOS

hope i have helped,

gewure

0

The answer would be no, as you are the first to do the most work. But you can still attack it.

The key in your question is distributed. Even if the attacker has the same amount (or almost the same), there are numerous clients to start a handshake. Meaning that you don't need to put all your effort in when doing a handshake, just divide the workload over different clients and no client may feel a real significant change in performance, whilst the server might be at its limit.

I think the trick is to start multiple SSL sessions, but never do anything more than saying HELLO, the server will reply and wait. This means you can DoS it with its resources and max amount of sessions at the same time. (a bit like a TCP SYN attack)

  • 1
    That doesn't really answer my question. All you're advising is a standard TCP flood, except I send a packet after the handshake. I'm trying to figure out if there's a workload imbalance at any point in the handshake, to make small botnets more effective. – Polynomial Aug 2 '12 at 12:06
  • The answer would be no, as you are the first to do the most work. – Lucas Kauffman Aug 2 '12 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.