JS challenge crypto calculations

[krizhanovsky]

It seems we can come to a good CAPTCHA alternative with the JavaScript challenge. This isn't a reverse Turing test, but just a slowing down of all users, not only bots, and blocking of JS-uncapable bots. Further development of th JS code can make mimicing of a real browser JS engine by a custom C code harder.

Currently, JS challenge uses a timer, which is easy to program on bot net side. The challenge instead must require some asymmetric calculation, e.g. prime factoring or any other crypto task. However, as we expect that the challenge is going to be programmed on bot net side, the task must not be widespread, e.g. to compute a hash function many times - it's too trivial to write 10-lines C code for solving the task. It's much better to require an attacker to write larger custom C code. Maybe some rare/old, maybe insecure, but not included into OpenSSL, cipher can be used.

If we can generate the JS code on-the-fly, then we can improve the challenge even more. E.g. we can at least insert delay_min and delay_range values in C code instead of using the Perl script. If we use hash functions, then we can use various strings (e.g. "sha256()", "md5(sha1(md5()))" and so on) to generate a JS code. If we generate thousands of JS code variants requiring complex parser (in case of custom C code for bots), then it will be much more expensive to launch a DDoS attack. The JS code can be generated in user space by the Perl script and loaded into the kernel with already computed answer to be added to the cookie. The script can generate and load a new JS challenge say once per second.

Having that a client can be a powerful desktop as well as outdated smartphone, we can not use upper JSC bound, so it must be revised. The most obvious, but fishy, way is just to make the upper bound "large enough". A better way is wished. Maybe we can combine the two methods, e.g. use the timeout value in the crypto challenge and run the computation in parallel with the timer, when Tempesta receives the challenge answer it must check the timeout and make a decision about probably missed the upper bound. However, it's still not good to require a heavy computations on small devices - user experience can go down significantly, so the challenge should be sent on #488 conditions - if a user is considered suspicious (just like reCAPTCHA does this).

The JavaScript code doing the computation must be minified and obfuscated by update_template.pl script.

Note. Making clients wait decreases user experience, so the timeout limitations should be rethinked and shouldn't be used as the main DDoS mitigation solution. Heavy computations on client side will also lead to high power consumption on mobiles, which could be quite crucial for web resource owners.

It seems there will be 2 versions of JS challenge, community and enterprise, so a new compile option for Tempesta must be introduced to generate C code for both the versions.

[krizhanovsky]

Moved to private repository for the enterprise releases.