Description of problem:

(This is not about insecure TLS negotiation but about a flurry of TLS renegotiation requests arriving on a server at the same time and overwhelming the server to the point of DoS.)

TLS renegotiation DoS attacks leverage the fact that regenerating new keys is done by the server and is both CPU- and time-consuming. Given a large enough number of clients requesting TLS renegotiations, the server (qdrouterd in this case) can exhaust CPU resources or simply fail to serve existing sessions.

Renegotiations are good and extremely important when used correctly, and ideally they would be rate-limited by the application (see [1] for reasons why TLS frameworks such as openssl and nss shouldn't implement it by themselves).


Version-Release number of selected component (if applicable):
qpid-dispatch-router-1.14.0-1.el7_9

How reproducible:
Apparently 100% if trying.

Steps to Reproduce:
1. On the latest Satellite 6.10.z release, enable katello-agent so as to set up qdrouterd on Satellite and any Capsules.
2. Have 1000s of hosts issue TLS renegotiation requests against qdrouterd's port 5647/tcp, and on Satellite also against 5646/tcp.

Actual results:
Qdrouterd will exhaust CPU resources and will fail to serve out legitimate TLS sessions, especially new TLS sessions that require the server side to generate new keys as part of the initial TLS handshake.

Expected results:
Qdrouterd would honor TLS renegotiation requests up to a given (sane) point, then it would start rejecting or dropping renegotiation requests if too many were already being handled.

Additional info:
This vulnerability is captured by Nessus: https://www.tenable.com/plugins/nessus/53491

Why OpenSSL should not be the one implementing rate-limiting for TLS renegotiation, and applications are the ones who should do it instead: https://bugzilla.redhat.com/show_bug.cgi?id=707065