Re: SoC: Improve syslogd

[Martin Schütte <lists%mschuette.name@localhost>]

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 
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
> loop.

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.

--
Martin