Bug 2101554

Summary:	Qpid dispatch router (qdrouterd) is vulnerable to TLS renegotiation DoS attacks
Product:	Red Hat Satellite	Reporter:	Pablo Hess <phess>
Component:	Qpid	Assignee:	Nobody <nobody>
Status:	CLOSED WONTFIX	QA Contact:	Satellite QE Team <sat-qe-bz-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.10.7	CC:	ehelms, kgiusti
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:	2024-02-07 18:16:21 UTC	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:36:41 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 (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

Comment 4 Brad Buckingham 2024-01-09 20:58:59 UTC

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 5 Brad Buckingham 2024-02-07 18:16:21 UTC

Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.