1360350 – gnutls module prevents logging if the TLS handshake is stuck

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1360350 - gnutls module prevents logging if the TLS handshake is stuck

Summary: gnutls module prevents logging if the TLS handshake is stuck

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	rsyslog
Sub Component:
Version:	7.4
Hardware:	All
OS:	Linux
Priority:	unspecified
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Tomas Heinrich
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1279514
TreeView+	depends on / blocked

Reported:	2016-07-26 13:22 UTC by Cedric Buissart
Modified:	2016-09-20 04:53 UTC (History)
CC List:	3 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-08-10 08:21:48 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Cedric Buissart 2016-07-26 13:22:57 UTC

Description of problem:
If TLS handshake does not succeed/fail, rsyslog is unable to log anything (i.e.: including locally).

Version-Release number of selected component (if applicable): all version, including upstream rsyslog 8 (I tested with versions 5, 7 and 8)


How reproducible: 100%/easy


Steps to Reproduce:
1. set up a TLS capable rsyslog client/server environment
2. drop a packet during the TLS handshake

Actual results:
Client is unable to log locally

Expected results:
Client should still be able to log locally.


Additional info:
I ll attach debug output of normal and 'stuck' behaviour for comparison.

Comment 5 Tomas Heinrich 2016-08-08 20:44:10 UTC

(In reply to Cedric Buissart from comment #0)
> Steps to Reproduce:
> 1. set up a TLS capable rsyslog client/server environment
> 2. drop a packet during the TLS handshake

I've tried to reproduce this but without luck so far.

> Actual results:
> Client is unable to log locally

If it's just the client, I suspect this might be a misconfiguration.
Could you attach the configuration you were using for the client?

Comment 7 Cedric Buissart 2016-08-09 12:59:36 UTC

attached everything. I hope it's sufficient.
I do not think there is anything incorrect with the configuration, but I could be wrong.

Comment 8 Tomas Heinrich 2016-08-09 15:11:08 UTC

Thanks for the data. Here are some remarks:

- you're loading the imuxsock plugin but at the same time you're disabling it with "$OmitLocalLogging on", thus it has no effect

- there's no queue configured for the forwarding action, so the messages are processed synchronously - once the fwd fails due to the iptables rule, none of the subsequent actions get executed


If you define a queue for the forwarding action, local logging should start working again.
If you can confirm this, I think we can close this.

Comment 9 Cedric Buissart 2016-08-10 08:21:48 UTC

Thanks for the tip! Indeed, with a queue, it does not hang any more.

E.g. :
$ActionQueueType LinkedList
$ActionQueueFileName forward_to_server
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
*.* @@<server>:10514 # forward everything to remote server

Note You need to log in before you can comment on or make changes to this bug.