[Help-gnutls] Re: Authentication during Handshake

[Simon Josefsson]

"Rainer Gerhards" <rgerhards at gmail.com> writes:

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

Until the TLS handshake has finished, the TLS protocol doesn't protect
against people in the middle.  It is not until the TLS Finished message
(which marks the end of the TLS handshake) that you can tell whether the
other end holds the private key corresponding to the certificate.

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

I understand.  I think this problem is one reason why the fingerprint
mechanism is considered a hack.

If you verify the fingerprint during the TLS handshake, you open up for
a man in the middle that can cause authentication failures to occur
without that being possible to detect.  Read that again carefully to
understand it -- it does not enable man in the middle attackers to read
any traffic, just that they can simulate a failed fingerprint
authentication.  If this moves forward in the IETF, that should be in
the security considerations.

Another problem this causes is hash agility: how can the protocol to
handle when SHA-1 is publicly broken and one needs to change to another
hash?  OpenPGP has a similar problem with key fingerprints, I think, and
I don't know of any simple solutions.

>> 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,
Simon