Hi Nelson, many thanks for your very useful reply. Comments inline...
On May 22, 12:41 am, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: > Rainer Gerhards wrote, > > >>> [snip] I would like to authenticate > >>> remote peers via custom authentication layed out in the standard. This > >>> is fingerprint-based, very similar to SSHs leap of faith auth. > > "Leap of faith auth". That's the perfect name of SSH's authentication. > Did you coin that phrase? That's a keeper. :) I am just reproducing - don't know the creator ;) > > >>> I would > >>> like to do this inside the TLS handshake, to be precisely after I > >>> received the remote peer's Certificate but before the Finished message > >>> is sent back. I am looking for something like a callback that calls me > >>> at this point and permits me to do a binary permitted/not permitted > >>> decision on the remote peer. This callback code must be able to > >>> examine the remote certificate. > >>> Please note that I am specifically asking for a callback inside the > >>> handshake. For technical reasons inside syslog, I would ideally need > >>> to authenticate the peer during the handshake procedure, NOT after it > >>> has completed. > >>> Is there any such functionality in NSS? If so, would it possible to > >>> point me to the relevant part of the documentation? > >>> All feedback is deeply appreciated. > > Julien R Pierre <[EMAIL PROTECTED]> replied: > > >> Right now there is no such callback available in NSS' libssl to do what > >> you want. > > Maybe I misunderstand the request, but I believe that libSSL offers exactly > what Rainer has requested. > > NSS's libSSL does not directly decide if ANY certificate is valid, or not. > It *always* uses a callback function to have that decision made for it > the the application. NSS's libNSS3 does provide a function that serves > this purpose very well for applications that want to adhere strictly to > the standards, but applications are free to register their own callbacks > for the purpose of deciding if a given certificate is authorized. Many > applications do register their own callback functions for this purpose. > All Mozilla's applications that use PSM do this, for example. > > The callback function is registered via a call to SSL_AuthCertificateHook(). > Seehttp://lxr.mozilla.org/security/source/security/nss/lib/ssl/ssl.h#214 Excellent, this was exactly what I have been looking for. > > >> Why do you want to use non-standard authentication ? SSL/TLS client > >> authentication is already available and standard. > > > The simple answer is because the upcoming standard requires it: > >http://ietfreport.isoc.org/all-ids/draft-ietf-syslog-transport-tls-12... > > > The more elaborate answer can be found in this post: > >http://www.ietf.org/mail-archive/web/syslog/current/msg01896.html > > In which the author rejects PKI because he thinks sysadmins will not use > PKI. Note that he not only "thinks" so but does so based on research and talking to lots of system administrators. Also please note that using fingerprints was suggested by Pasi Eronen, the same person that wrote the PSK draft. So this thinking is not a "my poor myself had a great idea" thinking but rather knowledge ad experience based ;) > > > To sum it up, fingerprints are used because the cost of PKI is > > considered too high for many use cases with syslog. > > SSL server certificates are available FOR FREE from at least one public CA > that is trusted in Mozilla products. Is free too high a cost? Definitely in many cases ;) In home environments, the cost of the certificate is probably important. In enterprises, it is more the cost of deploying and maintaining the PKI infrastructure. For example, an enterprise must make sure that each and every syslog receiver is integrated within the enterprise's PKI. > > Or is it a matter of sysadmin laziness? > Lazy sysadmins are the enemy of good security. > > > To make matters worse, I may even have problems with standard > > authentication. > > What problem would that be? That is not a TLS problem, but one based on syslog. Syslog is a simplex protocol. Once the TLS handshake has finished, the receiver has no ability to notify the sender of anything. The only thing it can do in case of error is drop the connection. That, of course, leaves the sender without a clue why it happened. So if authentication would need to happen after the handshake, the sender would need to drop the connection that the client is probably already sending data on. The result will be loss of data. The same happens with plain TCP if something goes wrong on the connection. The exact details can be found here: http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html As I said, the problem now no longer exists, as I can authenticate the peer during the handshake. Thanks again, Rainer _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
