Handshake before logs
02The sender opens TCP to the receiver, normally on port 6514, then starts TLS. The handshake exchanges options, checks peers and establishes protection keys. Finish the handshake and satisfy peer policy before sending syslog application data. Later RFC 9662 updates the cryptographic requirements.
Separate resumption example: stop syslog early data before delivery. RFC 9662 §6 MUST NOT use early data, even though TLS 1.3 itself offers the feature.
Source for this drawing: RFC 5425 · Read RFC section 4.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
TLS 1.2 remains mandatory to implement; TLS 1.3 SHOULD be supported and MUST be preferred when implemented. Both named legacy/ECDHE suites are mandatory to implement, with ECDHE preferred. Implementations MUST NOT use early data. Read the update for exact offer/support distinctions and migration limits.
Read the updated RFC section ↗Do not turn the 2009 cipher requirement into current deployment advice; early data is prohibited.
- TCP 6514 is the default, not a required port for every deployment (§4.1). §4.2 says the sender should initiate the connection and send Client Hello; after the TLS handshake finishes it MAY send the first message. This is direct TLS, not a STARTTLS command exchange.
- RFC 9662 §4 formally updates §4.2: TLS 1.2 remains mandatory to implement. Implementations SHOULD support TLS 1.3 and, if implemented, MUST prefer negotiating it over earlier TLS. Supporting a version is distinct from negotiating it on a particular connection.
- RFC 9662 §4 requires implementation of BOTH TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA; implementations SHOULD offer the ECDHE suite but MAY offer the RSA suite. §3 requires preferring the ECDHE suite for the migration. This is not a recommendation to deploy the old RSA/CBC suite; §8 calls for administrator evaluation where a legacy device still needs it.
- RFC 9662 §6 says implementations MUST NOT use TLS 1.3 early data (0-RTT), even on resumption. Syslog lacks replay protection. RFC 5425 §4.2.3 says resumed security parameters SHOULD be checked against the requested session requirements.
- Each endpoint MUST implement certificate-based authentication (§4.2.1); this is an implementation capability. Selected unauthenticated policies do not become mutually authenticated merely because encryption was negotiated. The drawings condense the handshake, not its packet-by-packet TLS transcript.
Update text: https://www.rfc-editor.org/rfc/rfc9662.html#section-4 and #section-6.
Read the RFC section ↗