From the linked page:
> TLS Blacklist
> To prevent padding oracle and other timing side-channel attacks, the HeavyThing library employs a TLS blacklist feature. When a decryption error occurs, by default the offending source IP address is added to a blacklist such that no further connections will be accepted for a period of a full 24 hours. Please note that the blacklist is not shared or synchronized between multiple rwasa processes, so what this really means is that -cpu worth of connections will be accepted at most per 24 hour period. Even if this setting is disabled, special care is taken such that no timing information is leaked during MAC failures. During the course of normal operations, decrypt errors do not (and should not) occur so if everyone plays nice with rwasa this setting goes largely unnoticed. It is our opinion that this strategy of automatically blacklisting clients who are tampering is an effective server-side mitigation technique.
They try to deal with timing attacks using IP address blacklisting. This piece of software is unlikely to be secure, if that's all of the timing channel mitigation they've done! "... special care is taken such that no timing information is leaked during MAC failures." suggests they're doing "something".
There are also other side channel attacks. Like cache timing related attacks when in a shared or virtualized environments. In this scenario, attacker's code would be running on same physical server and deducing private keys out of side channel leaks.
The best way is to have algorithms that perform constant work and take constant time for public key cryptography. Even if it costs performance. Unless you want to leak your keys in unexpected ways.