On 2021/10/11 15:50, Alexander Bluhm wrote: > On Sat, Oct 09, 2021 at 09:36:01PM +0100, Stuart Henderson wrote: > > This allows setting which TLS versions are usable by syslogd. Some > > environments require that TLSv1.0 is disabled. Manual wording stolen from > > ftp(1). any comments? ok? > > netcat and ftp allow to give TLS options as key=value. Maybe we > want that here, otherwise we could run out of option letters. Do > our users want specific ciphers or other things?
For my current use case, simply requiring 1.2 or newer is good enough and I don't need to set particular ciphers. I can change the implementation to use that method, but I wonder which options would be needed. There is only partial consistency between netcat and ftp so far, netcat: noverify, noname, clientcert, muststaple, ciphers, protocols (cafile and clientcert are implemented via flags other than -T) ftp: cafile, capath, depth, do, dont, muststaple, ciphers, protocols, noverifytime Following netcat's lead there is probably no need to move -C/-c/-K/-k to a different flag. Maybe there's some use case for noverifytime. ciphers/protocols make sense. noname/noverify don't seem to make much sense to me for syslogd. > Is it wise to set the same options for client and server TLS? > > When syslogd is relaying messages from dumb devices with broken TLS > stacks to modern SIEM systems, the requirements on both sides are > different. I avoided to dive too deeply into this question by using > sane defaults. I use "all" or "compat" cipher lists. > It seems for your use case the defaults do not match. > > 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. I would say at a minimum it needs setting server-side but it would be helpful to do client-side as well. 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.
