[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 @@10.1.2.3
1. connect to 10.1.2.3, 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 @@logs.example.org then there are additional steps:
0a. DNS lookup to get IP 10.1.2.3
4a. match given name "logs.example.org" 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
server.example.net, you will also accept incoming connections from it?
Most hosts should run 'syslogd -s', so they do not accept incoming
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.
Main Index |
Thread Index |