Subject: [Syslog] Fingerprint/handshake

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 19 May 2008 23:30:48 +0200

Quick question: must the fingerprint check be done as part of the TLS handshake? Or must (can?) it be done after the handshake completed?

From the draft i got the impression it must be done inside the handshake and handshake must fail if fingerprint auth fails.

A clarification would be most appreciated.

Thanks,
rainer
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 23 May 2008 11:20:30 -0700

The fingerprint check should be done where certificate validation would
be done.  This is typically done within the handshake itself, 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.   

Joe
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Monday, May 19, 2008 2:31 PM
> To: [email-masked]
> Subject: [Syslog] Fingerprint/handshake
> 
> Quick question: must the fingerprint check be done as part of 
> the TLS handshake? Or must (can?) it be done after the 
> handshake completed?
> 
> From the draft i got the impression it must be done inside 
> the handshake and handshake must fail if fingerprint auth fails.
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 26 May 2008 08:45:54 +0200

Hi Joe,

inline

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Friday, May 23, 2008 8:21 PM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] Fingerprint/handshake
> 
> 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

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 28 May 2008 17:31:41 -0700

Hi Rainer,

A TLS alert could be sent by the server indicating the error condition.
Would this help? 

Joe

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Sunday, May 25, 2008 11:46 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> 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.
> 
[Joe] Its been a while since I used OpenSSL, but if I remember correctly
they do have hooks in the certificate validation code. 

> 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).
> 
> 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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 29 May 2008 09:45:17 +0200

Inline...
> Sent: Thursday, May 29, 2008 2:32 AM

That's an interesting idea. Let me give it a try. Will provide feedback when I have done this. In any case, if it turns out to be a problem with one library, we may be better of mandating that all verification is done during the handshake...

> they do have hooks in the certificate validation code.

[Rainer]
From what I have seen in the doc, this does not permit to do all checks. Most importantly, it looked like I am not able to check the fingerprint and subject name. But fortunately Martin Schütte is using openSSL for his implementation and I hope he can provide feedback on this in the not so distant future.

Rainer

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 29 May 2008 10:12:04 +0200

> That's an interesting idea. Let me give it a try. Will provide feedback when I have done this. In any case, if it turns out to be a problem with one library, we may be better of mandating that all…

By the way, I've read in your implementation report that it is not
possible to terminate the handshake with OpenSSL either. This is not the
case, you can do that.

-- 
Bazsi

---

From: Rainer Gerhards <[email-masked]>
Date: Thu, 29 May 2008 12:44:07 +0200

> possible to terminate the handshake with OpenSSL either. This is not the

Ah, good to know. So it looks like this is a single-library problem,
about which the standard should obviously not care.

Bazsi, could you do me a favor and let me know which callback you use,
so that I can get to the specifics (also for the GnuTLS folks). I'd
really appreciate that.

Thanks,
Rainer

---

From: "tom.petch" <[email-masked]>
Date: Thu, 29 May 2008 11:14:27 +0200

Rainer

I wonder how a similar problem is handled.

Every so often, I see the performance of https: access go to pot, and when I
look, yes there is a multi-megabyte CRL being downloaded before the
authentication can complete.

I assume that you cannot know what certs you will get, so cannot preload the
CRLs so this is an inevitable part of PKI (and one I suspect will become a
significant problem).  Any idea what happens? Does the TLS exchange get held up?

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 29, 2008 9:45 AM
Subject: Re: [Syslog] Fingerprint/handshake

Inline...
> A TLS alert could be sent by the server indicating the error condition.

That's an interesting idea. Let me give it a try. Will provide feedback when I
have done this. In any case, if it turns out to be a problem with one library,
we may be better of mandating that all verification is done during the
handshake...

> they do have hooks in the certificate validation code.

[Rainer]
From what I have seen in the doc, this does not permit to do all checks. Most
importantly, it looked like I am not able to check the fingerprint and subject
name. But fortunately Martin Schütte is using openSSL for his implementation and
I hope he can provide feedback on this in the not so distant future.

Rainer

---

From: Balazs Scheidler <[email-masked]>
Date: Fri, 30 May 2008 07:17:22 +0200

> so that I can get to the specifics (also for the GnuTLS folks). I'd

In OpenSSL the complete peer validation process can be changed by using 
SSL_CTX_set_cert_verify_callback(), it gets X509_STORE populated with
the peer supplied key chain and returns whether the validation failed.

If the callback returns failure, an alarm is sent back to the peer
depending on the error code that is returned by this callback.

-- 
Bazsi