[Help-gnutls] Re: Authentication during Handshake

[Rainer Gerhards]

On Tue, May 20, 2008 at 10:31 AM, Simon Josefsson <simon at josefsson.org> wrote:

[snip]

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

Please bear with me, I am trying to fully understand it ;) Doesn't
that mean that authentication can never happen as part of the TLS
handshake? As you said, as long as I do not know thzat the remote peer
holds the correct private key, I can not trust anything. If that is
known only after the handshake, how can I authenticate the remote end
during the handshake? I have to admit that I was under the impression
that TLS handshake included the authentication. For example, GnuTLS
doc states in section 3.5 (first sentence):

The Handshake protocol is responsible for the ciphersuite negotiation,
the initial key exchange, and the ****authentication of the two
peers****.

Digging further down in the doc, however, the samples seem to do the
actual authentication only after the handshake. What, of course, makes
sense if you can't trust the cert during the handshake. ... but I have
to admit I am puzzled now ;)

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

I understood and I will propose to mention it in the security
considerations section.

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

This is actually handled: the fingerprint comes along with an
identification of the algorithm that was used the generate the
fingerprint. So it is possible, in a migration period, to support both
weak and strong algos. Applications implementing the draft need to
have capabilities to display the fingerprint. For the time being, my
initial implementation will support just SHA1, but once I have the
initial set done, I'll provision for additional algorithms. Of course,
they require actual implementation once they are defined. But that's a
different story...

Rainer