On Mon, Oct 11, 2021 at 03:44:54PM +0100, Stuart Henderson wrote: > I can change the implementation > to use that method, but I wonder which options would be needed.
I don't call for a complete feature monster to set all SSL options. But we should have consistency with netcat and the possibillity to extend the options. Unfortunately netcat and ftp are inconsistent and syslogd already has too many options. The question is when we stop adding TLS option letters. > noname/noverify don't seem to make much sense to me for syslogd. Ironically I have implemented -V to skip validation. Useful if you just want to send messages encrypted without caring about a PKI. > > Do you need TLS 1.0 disabled for receiving or sending side? > This is a good question. For my current use case as I understand it it's > enough to just not be _using_ pre-1.2 TLS, but it's easier to document > and prove if the earlier protocols are actually disabled rather than just > not used. So your use case is a compliance problem. Setting both sides makes sense then. But remember, in syslog context requiring strong encryption may be a bad thing. If a device supports only ancient TLS, people will use UDP instead, which is worse. > I didn't expect to see syslogd used to relaying messages from client to > a remote server, but now that you've described it, it makes complete sense > and I see how different settings for client and server would be useful > there. I don't want to reject your diff. It fixes one specific problem in an easy way. But in the long term separate TLS key=value pairs for client and server TLS seems more flexible. I was already running out of nice letters when I implemented all the -C -c -K -k -V flags. Additionally some /etc/ssl/ key and cert paths are hardcoded. The alphabet is not exhausted yet. But when we switch one day in the future, more old options have to be retired. bluhm
