[Help-gnutls] Re: Authentication during Handshake

[Simon Josefsson]

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

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

Heh.  The key to understanding this is that the TLS finish message acts
as the final check to make sure everything agreed on earlier in the
handshake is correct.  So if the finish message arrives and is decrypted
correctly, the authentication has worked fine.  Before that has happened
you only know that it may work out fine, but don't know for sure.  The
TLS handshake includes the TLS finished message, so if that worked fine,
you indeed have authenticated successfully.

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

Hm, that sounds strange.  Which example?  GnuTLS should verify the
certificate during the handshake (the CA is set before starting the
handshake), but the examples may be printing the data in the
certificates after the handshake.

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

I believe that would be a good idea.

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

Ok, that is as good as it is going to get with the fingerprint approach,
I think.

/Simon