[Help-gnutls] Re: Authentication during Handshake

[Rainer Gerhards]

On Mon, May 19, 2008 at 10:53 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
[snip]

>> In essence, I am looking for something like a callback that is called
>> during handshake with the remote cert and that can reply with auth
>> success/failure - all while in the handshaking porcess.
>>
>> Does that make any sense?
>
> Yes, although I'm not sure it is a good idea to do it as part of the
> handshake: until the handshake is over, you don't know whether there is
> a man in the middle attacker present.

I am (obviously;)) not a TLS expert. I thought that when I receive a
certificate during the handshake, I can validly assume that it
reflects the remote peer's identity. Could you enlighten me why there
is a man-in-the-middle attack possible? I would like to get this right
because I may need to bring it up inside the IETF discussion (and
obviously I want to be correct then ;)).

>I suggest completing the
> handshake as normal, and then compare fingerprints.  If fingerprint
> comparisons fails, shut down the TLS session.

Actually, this is what I am currently doing. BUT... the syslog story
is even worse ;) Syslog is simplex communication and the syslog TLS
internet draft in question maps this simplex nature onto a TCP stream
WITHOUT acknowledgments (except for the TCP ack, of course). While
this sounds quite strange, there are some good reasons for doing so (I
do not elaborate, because it would end up at a veeeeery long off-topic
post).

Of course, there are inherent problems. One is that after the
handshake completes, the sender  assumes it may send syslog messages.
When the server then drops the connection, some of these messages are
lost, but the sender can not detect which ones exactly. This is NOT
theoretical, I experience that in my lab. It was the reason I asked
the initial question. If you would like to dig deeper into that
problem, you can find a good description in a blog post I wrote a
while ago: http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html

The only solution to this problem is to have the fingerprint
authentication carried out during the handshake procedure - so that
the server does NOT need to drop the connection after the handshake
(at least not for authentication reasons).

> Ideally, I think the IETF draft should discuss some of these details.
> It is easy to implement ssh-style leap-of-faith authentication
> incorrectly.

I have also posted a question on the IETF list when exactly the
fingerprint authentication must happen. In my current understanding
(which may be wrong), the draft actually specifies it must happen
during handshake (which, as I said, would be the right thing here). I
have not yet received a reply. If you are interested, you may follow
the discussion here in the mailing list archive:
http://www.ietf.org/mail-archive/web/syslog/current/msg01910.html

Thanks again for your help.

Rainer