[Help-gnutls] Re: Authentication during Handshake

From:

Simon Josefsson

Subject:

[Help-gnutls] Re: Authentication during Handshake

Date:

Tue, 20 May 2008 12:51:41 +0200

User-agent:

Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)

"Rainer Gerhards" <address@hidden> 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