UniformDH should not block the main event loop
This isn't as big of a deal when gmpy is installed, but depending on how determined the adversary is, it still might be a problem.
I got curious I went and benchmarked the obfsproxy UniformDH implementation. On the test machine I used (i5-3320M), the generate + exchange takes ~24 - 25 msec (With gmpy it takes 3.8 msec).
Since the obfsproxy code does the key exchange in the main event loop, this means that on each incoming connection, the server will spend that much time doing the modular exponentiation and nothing else (To be pedantic for the obfs3 transport the attacker needs to only open a ton of TCP connections, even without sending anything to be successful).
Things that should be done:
- Use twisted.internet.threads.deferToThread to do the modular exponentiation in a thread pool, leaving the main event loop free to process other connections.
- Rate limit the number of incoming connections processed per interval to something sane. Also strongly consider rate limiting by source IP, so that an adversary at least has to get a bot net.
- modexp.powMod should also support using gmpy2 (Different import). Per the authors "gmpy2 is now the recommended version, especially if you use the pre-compiled versions for Windows."
- I do have a OpenSSL based implementation of the key exchange that is similar in performance to the gmpy based code. I could write a python module for it.