Bug 2101552

Summary:	TLS renegotiation cannot be rate-limited, thus leaves foreman-proxy vulnerable to renegotiation DoS attacks
Product:	Red Hat Satellite	Reporter:	Pablo Hess <phess>
Component:	Capsule	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	NEW ---	QA Contact:	Satellite QE Team <sat-qe-bz-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.10.7	CC:	aruzicka, ehelms
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pablo Hess 2022-06-27 19:28:59 UTC

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