Has anyone else in the mailing list had success with rsyslog gnutls? This has been an ongoing goal that can drone on about the experiences. It was a challenge to setup rsyslog v8.x with gnutls, as the config declarations are abnormally spread between globals and inputs.
It was confusing how to set ciphers along with some experimenting but successful to a point, and also probably not right, but we know the use of client library needs work, and so had to substitute with NSS configs to harden tls for rsyslog, but would be better if the application supported it native. http://www.gnutls.org/manual/gnutls.html#How-to-use-GnuTLS-in-applications https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Hardening_TLS_Configuration.html The rsyslog configs were not normal compared to typical v8 syntax that have used for tcp or ptcp, plus used debugging rsyslogd -N2 to find where parameters load. It seemed to have half working parameters for using internal certs with many clients, so tried using validation with common CA and wildcards appeared to be the solution, *.domain - although probably not as secure as it could be. Although can't recall exactly from memory what was required, but for the ciphers, had used gnutls-cli and gnutls certtool commands to generate certificates and verify what allowed ciphers are setup, also remember checking with openssl commands, to make sure everything in the nsswitch.conf or nss.conf set to only allow tls1.2 without the ciphers that have known vulnerabilities. Also did some experiments with tls and relp, but overall it was way too slow and didnt seem to work right. The tls alone setup was far from ideal and believe would not make it into prod environment until better supported and consistent config are available in rsyslog. Overall, looking back, it was kind of a hack anyway, especially odd with httpd for nss ciphers but seemed to do the trick although webserver was otherwise not used, and possibly be too strong for browsers ... webservers log clients might have needed to redo vhost configs or something, and I'm guessing would be the case if servers receiving logs actually need to host sites too. The rsyslog docs weren't very easy to traverse and find details as several reiterated info and left gaps, also some good older docs seemed to disappear with site changes over the years. As a side note, had ran into heartbleed when first attempting to compile libs for using gnutls on rsyslog v7 in prior years. After seeing the encrypted logs work on v8, had planned to contribute info back to the project after figuring out the configs, but will need to go back through on private lab from scratch and see what comes of it, hoping it will be less wacky the next time. I hope this rant is helpful to anyone, and will keep an eye on the topic since Rsyslog gnutls is something I'm interested in working on as time permits, or at least to test updated packages while am at it. Until then, stunnels or ssh forwarding might be a better alternative, but looking forward to others gnutls rsyslog success stories. Thanks! On May 24, 2016 4:16 PM, "David Lang" <[email protected]> wrote: > On Tue, 24 May 2016, Micah Yoder wrote: > > We have a PCI requirement to disable the RC4 cipher on our rsyslog TLS >> setup. I for the life of me can not find a configuration option to set the >> cipher suite. What am I missing? >> > > Unfortunantly, rsyslog's use of gnutls is very basic. It has very few > options. If there is anyone who is a guru in this area, we could use a lot > of knowlegeable help. > > Rsyslog trats the tls config as a black box providing the minimum config > items needed to make things work. > > It's possible that the library honors environment veriables for some of > these settings, if so you can work around the limits that way. > > Before rsyslog starting using gnutls, the work-around was to use stunnel > and run the logging traffic through stunnel. This still works. > > Patches to improve the control over gnutls would be very much welcome, but > the trouble if that there is already far too much confusion over getting it > to work, so just adding all the possible config options with good > explinations over what's what and when it should be used would only > increase the confusion. > > Someone who really knows this library could probably identify a smallish > subset of the options that we really should support and provide some sort > of explination as to what they mean pretty easily. > > > Unfortunatly this is why so many TLS related questions go unanswered for a > while here on the list. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
