[Help-gnutls] Re: Authentication during Handshake

[Simon Josefsson]

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

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

No, I think that is correct.  Nikos, any thoughts?  You added some
callbacks during the handshake earlier, are any of those useful here?

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

Ah, ok, what gnutls does in the handshake is the first step of the
authentication -- so that you know that the other end is the certificate
owner.  The rest above is mostly about authorization decisions.

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

No, that are authorization decisions that you need to do manually.  The
TLS handshake doesn't care whether the provided certificate is
untrusted.

/Simon