tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: SoC: Improve syslogd

Rainer Gerhards schrieb:
certificate. Checks will be against the common name and the subjectAltName
with DNS and IP entries.
I concur. Checking the protocol is also not included in the upcoming
standard - because there are no different protocol choices in it.

What I do still not fully understand (now) is how you would like to
have a client authenticate the server. Just based on the @@<hostname>.
If so, how do you do fingerprints?

I'm thinking along these lines:

0. Assume a configuration with @@
1. connect to, TLS handshake starts
2. send own cert, get its cert
3. verify certificate trust path, i.e. let the TLS library check against installed certificates (trust anchors) or check if its fingerprint is configured to be trusted. 4. match certificate and host, i.e. test if the subjectAltName contains the entry iPAddress: 0x0A010203 (cf. RFC5280). (I did not find a description how to use an IP as a common name, so I guess subjectAltName is the only option here)
5. if everything matches: handshake successfull
   otherwise: handshake fails, no connection

If configured with then there are additional steps:
0a. DNS lookup to get IP
4a. match given name "" against the certificate's common name or dNSName entries in subjectAltName.

Or do you want to use the same set of permissions for both client and
server operations? e.G. if you intend to send to host, you will also accept incoming connections from it?

Most hosts should run 'syslogd -s', so they do not accept incoming network connections.
But for relays and destinations: Yes.

I understand you desire for a simple design (and think you have a good
point with it), but I think at least sender and receiver permissions
must be different. For example, I would be very suspicious about a
server that I am sending to connecting back to me. This smells like a

If it is wanted then all TLS-options can be duplicated for incoming and for outgoing connections. But is this really a problem?
(Is anyone here using syslog relays?)
Constructing a loop is a serious configuration error that has been possible with UDP as well, should be noticed quickly enough, and cannot be detected if the loop has more than two nodes.
I do not think that TLS is the right layer to catch this.

As a side-note, have you already made up your mind which TLS library
you will probably use?

As Joerg wrote: OpenSSL is part of NetBSD and thus the only choice.


Home | Main Index | Thread Index | Old Index