Hi Joe, inline
> -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 8:21 PM > To: Rainer Gerhards; [email protected] > Subject: RE: [Syslog] Fingerprint/handshake > > The fingerprint check should be done where certificate validation would > be done. This is typically done within the handshake itself, I agree to this, but have found this to be problematic with some TLS libraries. Of course, that doesn't mean the standard needs to change, but I would still like to provide some implementation feedback. With GnuTLS, for example, you can do the final authentication only after the handshake [1]. With NSS, it can be done during the handshake. As of my understanding, OpenSSL does support it after the handshake only (but I have not actually used OpenSSL, this is based on my understanding after reading doc). This brings me to the conclusion that, at least in some environments I may be forced to delay the authentication check to after the handshake. > because if > the validation fails you do not want to send or receive data on the > connection. I suppose you could implement the check after the > handshake, but you need to make sure you do not send or receive > application before successful validation has occurred. This is where it gets really problematic. We get into a race condition here. Remember that syslog is simplex and works without any app-level acks (in -transport-tls). If the client authenticates the server, everything is fine. Authentication fails, client never sends data and the session is terminated. Everything is fine. But if the server authenticates the client (and authentication fails), the client will still receive the server's TLS Finished message. After that, the server drop connection. HOWEVER, the client blindly sending data doesn't know this until at least the second message sent (due to local buffering at the client). *After* some messages, the client gets a connection broken indication, but at this point it is too late to react intelligently. In essence, those messages sent after the initial handshake are lost. Even worse, the client "gets the impression" that the remote server is accepting its connection requests. This is because there is no failure indication after the handshake. This can lead to more frequent retries. This problem is rooted in the underlying plain tcp transport. I have described it in [2]. It's inherent to all plain tcp syslog implementations. RFC3195 is a cure for it. With TLS auth, it just gets to a new magnitude as it will now happen every time during a failed authentication. This is not a theoretic issue but one I can reliable reproduce in my lab with actual software. Actually, I am unable to NOT reproduce it - there is no work-around for this problem (at least I have found none). Again, I am not trying to say we need to change anything. I am providing real world feedback. It may be worth, however, adding a note or two to the I-D describing these issues. Rainer [1] http://lists.gnu.org/archive/html/help-gnutls/2008-05/msg00017.html (full conversation, long) [2] http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.ht ml _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
