Hi all, I am part of a laboratory that is required to test product conformance to protocol implementations as part of Common Criteria certification for said products. Recently we observed that a product using rsyslog to transmit data over TLS 1.3 is not behaving in a way that is consistent with RFC 8446. The RFC expects that if the TLS client has an active TLS 1.3 session and receives a TLS 1.2 Hello Request from the server that attempts to renegotiate the connection, the TLS client must terminate the connection. This is a change from TLS 1.2, which previously allowed the request to be discarded and ignored.
The current behavior of rsyslog appears to be to receive the TLS 1.2 Hello Request but not parse it as if it were TLS traffic. Instead, it simply receives it as if it were a raw TCP packet, responds with a TCP ACK, and allows the connection to continue unmodified. Based on our understanding, this violates RFC 8446. Using the underlying TLS protocol implementation (e.g. openssl, gnutls) allows us to see that they behave correctly on their own (e.g., if s_client is used to establish a connection to an arbitrary TLS server). This suggests the issue is specifically with respect to rsyslog itself. We note that syslog-ng exhibits the same behavior, which suggests that this is deliberate. My question is whether this is already a known issue in rsyslog, if it is the result of a deliberate decision, what the rationale for that decision was (Less processing overhead? Avoidance of denial of service attacks?), and whether this decision exposes rsyslog to any specific attacks or vulnerabilities. While we know that TLS 1.3 forbids renegotiation, we aren't sure why the RFC authors require an explicit rejection versus simply allowing the packets to be ignored, as rsyslog currently does. Any insights that could be provided here would be greatly appreciated. Regards, Justin Fisher | Leidos CCTL Laboratory Director Accredited Testing and Evaluation (AT&E) Lab [email protected]<mailto:[email protected]> | https://www.leidos.com/<https://www.leidos.com/CC-FIPS140> +1 (443) 367-7407 O | +1 (202) 997-6733 M | +1 (610) 468-2102 M _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
