If the TCP connections breaks without proper indication, the server side does not seem to clean some context or state. This results in the connection not being re-established after the network comes back, which breaks logging on the client because the log buffers run over and Syslog is designed to block in that case. Attacker who is able to break the TLS connection over the untrusted network, can cause DoS on the server for rsyslog service.
Created rsyslog tracking bugs for this issue: Affects: fedora-all [bug 1279515]
Original bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804525
This issue occurs when the remote receiver does not complete TCP handshake, acking the CLIENT HELLO but not sending SERVER HELLO back. Socket appears to be established, but in fact it waits for the handshake to complete, blocking all the other logging while queuing for the remote connection.
The problem is resolved by having a queue for the forwarding action, allowing to get the network part asynchronous. E.g. : $ActionQueueType LinkedList $ActionQueueFileName forward_to_server $ActionResumeRetryCount -1 $ActionQueueSaveOnShutdown on *.* @@<server>:10514 # forward everything to remote server See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-working_with_queues_in_rsyslog.html
All versions of rsyslog shipped support queuing. Therefore I am closing this flaw NOTABUG.