[Help-gnutls] Re: Authentication during Handshake

Simon Josefsson simon at josefsson.org
Tue May 20 12:51:41 CEST 2008

"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


More information about the Gnutls-help mailing list