Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
@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
up vote 0 down vote accepted

As far as I know, the server does not have to do more work than the client. For tradtional SSL, the client chooses a secret and encrypts it with the public key from the certificate. This is then sent to, and decrypted by, the server.

However, the computational work done by the server is much higher than with non-SSL connections, so less bots would be needed to achieve the same result, i.e. the resources of the server being exhausted.

In this paper they propose a protection mechanims against SSL-DoS by introducing client-side puzzles which shifts the computational load more to the side of the client.

share|improve this answer

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.

share|improve this answer

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)

share|improve this answer
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 posting your answer, you agree to the privacy policy and terms of service.

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