The State of transport-tls and its Implementation

Now the latest internet draft for transport-tls is out for two weeks now and it looks like a consensus on the text is found — at least there were no comments so far. I spent the better part of these two weeks changing and debugging my own implementation of transport-tls, which is far beyond the schedule but at least in time to have a working and usable program for mid-term evaluation…

So this is a good time to re-read the draft and check its requirements against my current syslogd code:

The TCP port NNN has been allocated as the default port for syslog over TLS, as defined in this document.

Nothing to do here as syslogd depends on /etc/services for its port (unless configured otherwise).

Implementations MUST support TLS 1.2 [I-D.ietf-tls-rfc4346-bis] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported.

I depend on OpenSSL to implement this.

Both syslog transport sender (TLS Client) and syslog transport receiver (TLS server) MUST implement certificate-based authentication.
o  Certification path validation: The TLS peer is configured with one or more trust anchors (typically root CA certificates), which allow it to verify a binding between the subject name and the public key.


Implementations MUST support certificate fingerprints in Section 4.2.2 and MAY allow other formats for end-entity certificates such as a DER encoded certificate.

Check for both.

Both transport receiver and transport sender implementations MUST provide a means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism.

Coming soon…

Update (for completeness): Now implemented. When given a config option and the certificate/key files cannot be read, then a 1024-bit RSA key is created and used for a self-signed X.509 certificate with the hostname as CN.

The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data.

In form of a log message:
Accept client certificate from due to matching hostname/subject.Subject is "localhost", fingerprint is "SHA1:E4:E1:A6:1C:D4:31:D7:D4:9B:B8:DC:DF:DD:CE:30:71:46:00:92:C9"

Both client and server implementations MUST make the certificate fingerprints for their certificate available through a management interface.

Could I say the shell is my “management interface” and provides the fingerprints with “openssl x509 -in xyz.crt -noout -fingerprint“?  :-)

Anyway, the used certificate is logged on server start and looks like this:
syslogd: Initialize SSL context using library "OpenSSL 0.9.8h 28 May 2008". Load certificate from file "localhost.crt" with CN "localhost" and fingerprint "SHA1:E4:E1:A6:1C:D4:31:D7:D4:9B:B8:DC:DF:DD:CE:30:71:46:00:92:C9"

Implementations MUST support SHA-1 as the hash algorithm and use the ASCII label “SHA1” to identify the SHA-1 algorithm.

Hashing is provided by OpenSSL again; syslogd will support/recognize all algorithms that OpenSSL’s EVP_get_digestbyname() supports.

Syslog applications SHOULD be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire.

There are different ways to authenticate the peer’s certificate.
The cryptographic level is not configurable, because I do not see the demand for that. (If indeed required then every OpenSSL setting, especially the list of usable ciphers, could be turned into a syslog.conf option.)

TLS permits the resumption of an earlier TLS session or the use of another active session when a new session is requested, in order to save the expense of another full TLS handshake.  The security parameters of the resumed session are reused for the requested session.  The security parameters SHOULD be checked against the security requirement of the requested session to make sure that the resumed session provides proper security.

I do not implement TLS session resumption, because I expect a syslogd TLS connection to last for some hours or days so the handshake cost is negligible.

All syslog messages MUST be sent as TLS “application data”.


A transport receiver MUST use the message length to delimit a syslog message.  There is no upper limit for a message length per se.  However, in order to establish a baseline for interoperability, this specification requires that a transport receiver MUST be able to process messages with a length up to and including 2048 octets.  Transport receiver SHOULD be able to process messages with lengths up to and including 8192 octets.

syslogd has no fixed limits on message lengths. On connection establishment a 2048 byte input buffer is allocated, longer messages will cause a realloc(). If that fails, then one message will be skipped.

A TLS client MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later.

I wrote a syslogd — it always expects to deliver more messages  ;-)

It MUST send a TLS close_notify alert before closing the connection.  A client MAY choose to not wait for the server’s close_notify alert and simply close the connection, thus generating an incomplete close on the server side.  Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the client (e.g., the closure was indicated by TCP).

Check. Although I make no difference between client and server mode and always shutdown the TLS connection.

When no data is received from a connection for a long time (where the application decides what “long” means), a server MAY close the connection.

There is no timeout implemented.

Implementations MUST support specifying the authorized peers using certificate fingerprints, as described in Section 4.2.1 and Section 4.2.2.


Implementations MUST support specifying the authorized peers using locally configured host names, MUST support certification path validation [RFC5280] and matching the name with the certificate as follows: […]

I match a given subject against SubjectAltName/dNSName, SubjectAltName/ipAddress, and commonName.
I just do not support the wildcard matching for hostnames (which is a MAY). I do want to but it has a really low priority on my TODO-list.

Comments are closed.