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 (foreman-proxy 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). Apache httpd can rate-limit TLS renegotiations but foreman-proxy's webrick apparently can't, at least with what's offered in smart proxies. Version-Release number of selected component (if applicable): foreman-proxy-2.5.2-1.el7sat.noarch all previous foreman-proxy versions. How reproducible: Apparently 100% if trying. Steps to Reproduce: 1. Install foreman-proxy as part of a Satellite or Capsule setup. 2. Have 1000s of hosts issue TLS renegotiation requests. Actual results: Foreman-proxy 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: Foreman-proxy 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