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?
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.
Yes, there are such points. Especially if SSL-Renegotiation is active, those can be exploited in order to bring down a server quite effectively:
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
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)
