Hi!
I'm using stunnel to secure an AMQP message broker (RabbitMQ, specifically) using pre-shared certificates. This means that my backends never get to see the SSL certificate that the client used to connect -- unfortunately, it's that very backend that's the first who can decide if a message is malicious or not.
In order to sort-of fix this problem, I'm using UUIDs so that the keyspace is so absurdly huge that the odds that someone will guess a key are second to none. Still, if someone is misbehaving (trying a large number of bogus keys) it would be nice to know who it is so I could stop wasting CPU time and bandwidth on them. So, I was wondering if anyone has used stunnel (vanilla or modified) to keep statistical data about who connects (which certificates).
Additionally, does anyone know of a decent way to throttle per-certificate (or limit the amount of tunnels that can be opened per certificate). If all else fails I could just do normal throttling on a per-IP basis, which should get me roughly the same thing. The reason I want this is because I want to prevent users from even *trying* a large number of such keys (even though it's statistically unlikely that they'll get one) since it still takes me CPU time to process that junk.
Thanks in advance Laurens
Laurens Van Houtven wrote:
In order to sort-of fix this problem, I'm using UUIDs so that the keyspace is so absurdly huge that the odds that someone will guess a key are second to none. Still, if someone is misbehaving (trying a large number of bogus keys) it would be nice to know who it is so I could stop wasting CPU time and bandwidth on them.
IMHO it should be possible to check between 2^10 and 2^14 keys per second with this attack. To succeed the attacker would need (on average) 2^128 / 2^14 / 2 = 2^113 seconds Since the universe is only 1.5 * 2^58 seconds old this approach is not really practical (as you noticed). IMHO it's better to implement some generic DoS countermeasures rather than protect against this specific attack.
Best regards, Mike