TLS 1.3 Client Log handling of Key Update Handshake Records

[asant57]

AxoSyslog

Version of AxoSyslog

syslog-ng 4.8.1 w/ OpenSSL 3.0.8

Platform

Ubuntu 24.04

Debug bundle

Issue

The Syslog-NG TLS client log exporter does not obey Handshake Records which are issued by the server once the TLS 1.3 session has been established. This is of particular concern with regard to TLS 1.3 for the Key Update handshake record which can be issued by the server to require the client to update the keys that are used by the client.

Steps to reproduce

1. Configure syslog-ng to forward logs to a remote syslog server over TLS 1.3.
2. Start a TLS implementation on the remote syslog server (e.g. OpenSSL s_server).
3. Cause the TLS server to issue the 'Key Update' Handshake Record with the 'update_requested' value set.
4. ISSUE HERE: observe that the syslog-ng client does not respond to the 'Key Update' record as required by RFC 8446 (https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.3)

## Configuration
cat /syslog-ng.conf
#############################################################################
# Default syslog-ng.conf file which collects all local logs into a
# single file called /var/log/messages.
#

@version: 4.8
@include "scl.conf"

source s_local {
        system();
        internal();
};

source s_network {
        default-network-drivers(
                # NOTE: TLS support
                #
                # the default-network-drivers() source driver opens the TLS
                # enabled ports as well, however without an actual key/cert
                # pair they will not operate and syslog-ng would display a
                # warning at startup.
                #
                #tls(key-file("/path/to/ssl-private-key") cert-file("/path/to/ssl-cert"))
        );
};

destination d_local {
        file("/var/log/messages");
        file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};

log {
        source(s_local);

        # uncomment this line to open port 514 to receive messages
        #source(s_network);
        destination(d_local);
};

destination d_tls {
        network(
                "172.16.0.7"
                port("7169")
                transport(tls)
                tls(
                        ssl-options(no-sslv3,no-sslv2,no-tlsv12,no-tlsv11,no-tlsv1)
                        ca-file("/etc/syslog-ng/ssl/RootCA.crt")
                )
                time-reopen(5)
        );
};

log { source (s_local); destination(d_tls); };

Input and output logs (if possible)

[bazsi]

Thanks for the detailed report @asant57

[MrAnno]

Hi,

Thank you. I've reproduced the issue, I'm working on the fix.

[MrAnno]

@asant57 #609 fixes the KeyUpdate issue, but I couldn't verify the other scenario (unexpected TLS 1.2 message after the handshake) you showed us privately.

If you have the time, would you mind trying the fix with the test case you showed us? I can provide .deb, .rpm packages, or container images, whichever works best for you.

[asant57]

A .deb package would be the easiest for me to verify the updates with.

[MrAnno]

Here are the packages for testing purposes (they only work for logged-in users):

Ubuntu 24.04: https://github.com/axoflow/axosyslog/actions/runs/14814982939/artifacts/3056303813

Debian 12: https://github.com/axoflow/axosyslog/actions/runs/14814982939/artifacts/3056300454

Debian testing: https://github.com/axoflow/axosyslog/actions/runs/14814982939/artifacts/3056300384

[asant57]

@MrAnno, Confirming that the provided Ubuntu 24.04 package is handling the KeyUpdate records as expected. Additionally, the client is now correctly rejecting any unexpected messages that are sent by the server.

[MrAnno]

Perfect, thank you. We'll merge it soon.

[MrAnno]

@asant57 Thank you again for catching this issue.

The fix will be included in AxoSyslog 4.12.0.