Hi there, I have today released a basic version of rsyslog with an experimental first -transport-tls implementation (announcement at http://www.rsyslog.com/Article222.phtml ). I am now digging deeper and refining the implementation. I try to convey some thoughts and ask some questions along this route - in the hopes to gather some feedback.
The initial feedback is that it is quite trivial to implement -transport-tls - just as anticipated. But I think it is good to see it works out in practice. My first question is on section 4.2. It does not tell what to do if the TLS handshake fails. One can argue that the second sentence implies that the connection should be dropped on handshake failure. However, this is not explicitly stated. It may be desirable to continue without TLS in that case. When GSSAPI support was implemented in rsyslog, there was a strong community demand for such a fallback mode. Thus, if the GSSAPI handshake fails, and rsyslog is configured accordingly, it falls back to plain TCP syslog (unencrypted). I know this is dangerous, as a man in the middle may force unencrypted transfer in this case. But provided it is an operator-selectable option (and by default off), I think it is an acceptable risk. Question now: how to handle this in spite of -transport-tls? With the current text, would my application compliant to it if it permits to run without TLS support when the handshake fails (in that case obviously not complying to any standard)? I would suggest that this case is being at least mentioned. I would also like to hear some opinions on this topic. Thanks, Rainer _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
