"Rainer Gerhards" <[EMAIL PROTECTED]> 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
