Re: [Syslog] Fingerprint/handshake

Hi Joe,

inline

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> Sent: Friday, May 23, 2008 8:21 PM
> To: Rainer Gerhards; syslog@ietf.org
> 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
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog