skip to content

What does moving syslog from UDP 514 to TLS on TCP 6514 fix, and what does it still not guarantee?

level: middleimportance: should knowfreq 25%

answer

  1. retransmission and back-off
  2. a length before every message
  3. certificates on both ends
  4. secure per hop, not per message
  5. no receipt from the application

basics

~20 s

RFC 5425 adds TCP retransmission and congestion control, octet-counted framing, encryption, integrity and certificate authentication on each hop. It has no application acknowledgement, so a broken connection can lose messages unnoticed, and it does not prove who wrote a message across relays.

solid answer

~40 s

With RFC 5425 the transport sender is a TLS client connecting to the receiver on TCP `6514`. TCP retransmits and backs off, so a burst no longer silently overruns the path, and TLS gives confidentiality, integrity and, with certificates checked on both sides, protection against a masquerading sender or collector. Each message is framed as `MSG-LEN SP SYSLOG-MSG`, a decimal octet count, so embedded line feeds cannot split it; receivers must handle 2048 octets and should handle 8192. What it does not fix: there are no application-layer acknowledgements, so if the connection breaks the sender cannot always know what was delivered; protection is hop-by-hop, and the certificate identity need not match the message's HOSTNAME, so origin needs RFC 5848 signing; and a reliable sender can block when the collector stalls.

go deeper

for a junior

Know that secure syslog runs over TLS on TCP port 6514, while classic syslog uses UDP port 514 with no encryption or delivery guarantee.

for a middle

Explain octet-counted framing and why newline framing broke, the 2048 and 8192 octet receiver sizes, and the certificate options: path validation or fingerprints.

for a senior

State the limits precisely: no application acknowledgement across a reconnect, hop-by-hop protection through relays, certificate identity versus HOSTNAME, and blocking under back-pressure.

for a principal

Weigh reliable transport's blocking risk and certificate operations against UDP's silent loss, and decide where signed syslog is required for evidence beyond hop-by-hop TLS.

## The two transports side by side RFC 5424 makes the TLS transport of **RFC 5425** mandatory to implement and recommended for deployment; the UDP transport of **RFC 5426** is a should-support for compatibility. | Concern | UDP 514 (RFC 5426) | TLS on TCP 6514 (RFC 5425) | |---|---|---| | Loss in the network | silent | TCP retransmits | | Congestion | no control | TCP backs off | | Message boundaries | one message per datagram | octet count before each message | | Minimum size receivers must accept | 480 octets IPv4, 1180 IPv6; should 2048 | 2048 octets; should 8192 | | Confidentiality and integrity | none | TLS, per hop | | Peer authentication | none | certificates, ideally both directions | | Application acknowledgement | none | none | ## Framing: why a length comes first Over a byte stream, the receiver needs to know where each message ends. RFC 5425 section 4.3 defines: `SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG` `MSG-LEN` is the decimal number of octets in the message, starting with a nonzero digit, and the receiver must use it to delimit messages. Several frames may share one TLS record, and one frame may span several records. Two messages from `fw-a` look like this, shown on two lines for reading; on the wire the second count follows the last octet of the first message directly, with nothing between them: ``` 115 <134>1 2026-10-01T14:03:07.412+02:00 fw-a.example.net fwlog 812 DENY - deny tcp 203.0.113.50:51514 to 192.0.2.10:22 93 <131>1 2026-10-01T14:03:07.415+02:00 fw-a.example.net fwlog 812 LINK - interface outside down ``` Each count covers every octet from the `<` of the PRI to the last character of the message, and the single space after the count is not included. The older alternative, plain TCP described in **RFC 6587**, is a **Historic** document recording legacy practice. It saw two framings: octet counting, the same idea, and **non-transparent framing**, where each message ends with a trailer character, usually a line feed. Because the trailer is not escaped, a message containing a line feed is read as two messages. RFC 6587 observes that a receiver can tell the two apart because an octet-counted frame starts with a digit and a non-transparent frame starts with `<`. ## Authentication policies RFC 5425 requires both sides to implement certificate-based authentication with two validation methods: certification path validation to a trust anchor, and matching configured end-entity certificate **fingerprints** (SHA-1 support required, labelled `sha-1`), which lets self-signed certificates work without a PKI. The policies it discusses: - **Mutual authentication and authorisation**: the recommended default; counters masquerade, modification and disclosure. - **Unauthenticated sender**: the collector accepts any client; not recommended, since it admits forged data. - **Unauthenticated receiver**: the sender talks to any server; not recommended, since logs may be disclosed to an impostor. - **Neither authenticated**: protects against none of the threats; not recommended. If a peer fails the policy, the TLS handshake must be aborted with an alert. RFC 5425 requires support for TLS 1.2 and says it applies to later TLS versions too. ## What TLS still does not guarantee 1. **Delivery confirmation.** RFC 5425 section 6.3: there are no application-layer acknowledgements, so if the TCP connection or TLS session breaks, the sender cannot always know which messages reached the syslog application. Data accepted by the local TCP stack can die with the connection. A `meta sequenceId` lets the collector see the gap. 2. **End-to-end protection.** TLS secures each hop. Through a relay, the message is in clear text inside the relay, and the authenticated peer at the collector is the relay. 3. **Origin.** RFC 5425 says the authenticated identity of the transport sender is not necessarily related to the message's HOSTNAME. Proving who wrote a message needs **RFC 5848** signed syslog. 4. **Never losing anything.** RFC 5424 section 8.5 warns that reliable delivery means the sender must block when the receiver cannot accept more, and a blocked logging process can stall a host. Implementations may instead discard deliberately, and the advantage is that they then know about it and can tell the collector. 5. **Defence against flooding.** RFC 5425 lists denial of service as a threat it does not address. ## Choosing it for the incident case For a firewall pair logging to one collector, TLS on 6514 turns silent network loss into retransmission and gives the collector authenticated, private messages. It does not remove the need to size the collector and to number messages so that gaps across a reconnect remain visible. Certificate lifecycle on both ends becomes part of keeping logging up: a certificate the peer no longer accepts makes the handshake fail, and the stream stops until it is fixed.

  • Why did newline-delimited syslog over plain TCP split some messages in two?
    RFC 6587, a Historic document, describes non-transparent framing: each message ends with a trailer, usually a line feed, that is not escaped inside the message. A message containing a line feed is therefore read as two. RFC 5425 avoids this with an octet count before each message.
  • The TLS session to the collector drops in the middle of a burst. Which syslog messages arrived?
    The sender cannot always tell. RFC 5425 has no application-layer acknowledgement, so messages accepted by the local TCP stack but not yet delivered can be lost with the connection. The collector can find the gap from `meta sequenceId` values once the sender reconnects.
  • Does a syslog sender's TLS client certificate prove the HOSTNAME in each message it sends?
    No. RFC 5425 says the authenticated identity of the transport sender is not necessarily related to the HOSTNAME field; through a relay, the certificate belongs to the relay. Proving which originator wrote a message requires RFC 5848 signed syslog.

saying these in an interview costs you the question

  • Syslog over TLS confirms delivery of every message to the collector.
  • The TLS client certificate proves the HOSTNAME in each syslog message.
  • Syslog over TLS ends each message with a newline character.
  • TLS on port 6514 protects a message end to end through every relay.
  • Plain TCP syslog is a Standards Track alternative to the TLS transport.