Last year we published research that several TLS implementations were still vulnerable to the classic "Bleichenbacher" attack from 1998 and named it the ROBOT attack .
While analyzing several implementations we also figured out inconsistencies with haskell-tls, but as we couldn't really make sense of them we haven't analyzed them in more detail.
We observe that in some situations as a response to faulty RSA encryption packages a haskell tls server will answer with an internal server error instead of a bad_record_mac error. The behavior is inconsistent, so we're not sure this can be turned into a practical attack. Yet it's still definitely a bug and potentially a vulnerability.
This only happens with ciphers with AES256 and CBC mode. (Which is also why our detection script and many other detection tools that are based on it will not see it, as they often will just test with AES128.)
It was originally pointed out to us by Hubert Kario (he's the developer of tls-fuzzer, which will show errors if you run its bleichenbacher check  against a haskell tls server). Another tool that's capable of detecting the error is TLS-Attacker, which is by one of ROBOT's co-authors .
A test run would be something like this:
java -jar Attacks.jar -loglevel DEBUG bleichenbacher -connect [host] -cipher TLS_RSA_WITH_AES_256_CBC_SHA
The issue can be subtle, because not only must one not provide a signal to the attacker that the padding check failed, but these days one is also expected to do so in "constant time", that is there should also not be a timing side-channel that allows an adversary to determine whether the padding check succeeded or failed. This can be difficult.
When I looked at this I did not see any issue directly related to RSA encryption.
Same behaviour is also shown in #289, consequence of the X448 issue.
Also, compared to the description, I reproduced the "internal_error" alert easily with AES128 too.
$ python scripts/test-bleichenbacher-workaround.py 'zero byte in random padding - TLS_RSA_WITH_AES_128_CBC_SHA'
zero byte in random padding - TLS_RSA_WITH_AES_128_CBC_SHA ...
AssertionError: Expected alert description "bad_record_mac" does not match received "internal_error"
it seems to me like trytls is more focusing on configuration (is SSL3 enabled, is MD5 enabled, ...) and bugs in X.509 handling (are small keys rejected, ...) - while the former can be done with tlsfuzzer, the latter is explicitly out of scope for tlsfuzzer, so it looks to me like they are complementary not a replacement for each-other