According to RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" -- the counterpart of RFC 5424 -- namely section 4.3 "Sending data", the proper framing for syslog over TCP with TLS is:
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
SP = %d32
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
(I.e. the message is prefixed with the bytes count of the entire frame.)
However looking in the remote_syslog2 implementation it seems it just appends an \n (and cleans the original message):
|
case *net.TCPConn, *tls.Conn: |
|
l.conn.netConn.SetWriteDeadline(deadline) |
|
_, err = io.WriteString(l.conn.netConn, p.Generate(l.tcpMaxLineLength)+"\n") |
Thus my question is if remote_syslog2 is actually compliant with RFC 5425?
(The documentation doesn't seem to state that it is compliant, however it keeps mentioning TLS and thus seems to hint so.)
According to RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" -- the counterpart of RFC 5424 -- namely section 4.3 "Sending data", the proper framing for syslog over TCP with TLS is:
(I.e. the message is prefixed with the bytes count of the entire frame.)
However looking in the
remote_syslog2implementation it seems it just appends an\n(and cleans the original message):remote_syslog2/syslog/syslog.go
Lines 193 to 195 in 09062fc
Thus my question is if
remote_syslog2is actually compliant with RFC 5425?(The documentation doesn't seem to state that it is compliant, however it keeps mentioning TLS and thus seems to hint so.)