[Help-gnutls] Re: Authentication during Handshake

[Rainer Gerhards]

On Tue, May 20, 2008 at 11:28 AM, Simon Josefsson <simon at josefsson.org> wrote:
> "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.

Thanks for your persistence. I think I at least begin to understand (I
am also reading RFC 4346 in parallel, but that's a lot to grasp at
once ;)). Let me sum up to see if I got it right:

I may check the remote peer's identity during the handshake, but it is
not guaranteed that the identity presented is the real identity. The
threat is that a man-in-the-middle may pretend to be someone else and
I may base a decision on this wrong identity. If I permit access, that
is not a problem, because the MITM would not be able to decrypt
(provided cert's pub key is used by me and the original entities
private key is not breached). However, the MITM may try to force me to
use lower security by providing a wrong identity. However, that would
result in no message flow at all in the syslog scenario. So the worst
case would be a denial of service, which could be created even without
authentication if the MITM simply steals the port and does not accept
connections.

I still would see a lot of benefit in being able to check the remote
peers identity BEFORE the Finished message is sent. That way, I could
block access to not permitted peers at the risk of the DoS outlined
above. Am I still overlooking something?

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

For example the example in section 7.3.4:

------
7.3.4 Verifying Peer's Certificate

A TLS session is not secure just after the handshake procedure has
finished. It must be considered secure, only after the peer's
certificate and identity have been verified. That is, you have to
verify the signature in peer's certificate, the hostname in the
certificate, and expiration dates. Just after this step you should
treat the connection as being a secure one.
------

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

Does it really *verify* the certificate or validate it in regard to
cert chain, expiration date etc?

[snip]

Rainer