Since Syslog TLS is taking the approach of a separate TCP port for TLS I think it would be more appropriate to reject the connection instead of falling back to insecure. I am inclined to say that if the handshake fails the connection MUST be terminated. If the client wants an insecure session they can connect to the insecure port.
Joe > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Tuesday, May 06, 2008 5:38 AM > To: [email protected] > Subject: [Syslog] -transport-tls, section 4.2 > > 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 > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
