Re: [Evolution-hackers] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded
On Tue, 2012-11-13 at 11:18 +0100, Christian Hilberg wrote: > My question now (for documenting the status quo) is whether anyone > is currently working on getting certificate-based client authentication > utilizing a TPM flying in Evolution for OpenLDAP+GnuTLS at present > or whether there are any plans to support this use case in the > near future. No one is working on it at the moment, and I don't see it being supported in the near future without sufficient demand or external contributors. I can't speak for Milan, but for me it's more ignorance in this area than objection or lack of interest. I will say that I'd like to see Evolution (Camel in particular) stop talking directly to NSS and defer certificate management to the various security libraries and APIs in the GNOME platform -- p11-kit, libgck, GTlsCertificate in libgio, etc. We haven't even begun to utilize these libraries yet (except perhaps through libsoup), and I sense there's a lot of redundancy in our code that could be eliminated by doing so, not to mention automatically gaining more consistent and probably improved behavior. But not yet being very familiar with these libraries, at present I can only make hand-wavy motions in their general direction. I'm hoping next year we can start taking real steps in that direction. That's the best answer I can offer for now. In the meantime, maybe consider using a Virtual Private Network. ;) Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded
Hi, Am Dienstag 13 November 2012, um 11:18:07 schrieb Christian Hilberg: > Hi everyone. > [...] > GnuTLS, as a replacement for NSS, adds another layer of complication > to the matter. Aside from the TPM user PIN, it requires the higher > level software to locate the correct client certificate for the > connection to be established inside the TPM (or a software emulation > thereof) via so-called "PKCS #11 URIs" in an explicit manner. There This [9] is how that is supposed to work in the latest GnuTLS (support in the 2.12.x series works much the same). Kind regards, Christian > [0] https://live.gnome.org/Evolution/Kolab > [1] https://mail.gnome.org/archives/evolution-hackers/2010-July/msg00076.html > [2] > http://sourceforge.net/projects/evolution-kolab/files/Usage_of_software_security_devices_for_client_authentication.pdf/download > [3] http://sourceforge.net/projects/opencryptoki/ > [4] http://trousers.sourceforge.net/ > [5] http://www.openldap.org/ > [6] http://www.gnu.org/software/gnutls/gnutls.html > [7] https://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 > [8] http://www.openldap.org/lists/openldap-technical/201009/msg00350.html [9] http://www.gnu.org/software/gnutls/manual/gnutls.html#Trusted-Platform-Module -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded
Hi everyone. During the initial implementation of evolution-kolab [0] back in 2.30 days, we evaluated [1] the chances to secure the protocols used to talk to the Kolab server (IMAP, SMTP, HTTP, LDAP) via TLS and having the server request the client to authenticate itself via a client certificate which is retrieved from a trusted platform module (TPM) or a software emulation of a TPM. We got this working for the IMAP, SMTP and HTTP protocols [2], involving the Mozilla NSS library and a PKCS #11 software stack (opencryptroki [3] and trousers [4]). However, we ultimately failed back then to secure the LDAP connection that way. The OpenLDAP [5] protocol library as used in Evolution relies on GnuTLS [6] for transport layer security. In contrast to NSS, GnuTLS requires the library on top of it (OpenLDAP in our case) or the application using both (Evolution in our case) to deal with security details. In order to access a TPM, a user PIN needs to be provided via a callback function. This is all NSS requires, as it handles locating the certificate in an opened TPM all by itself, depending on the connection type and peer. OpenLDAP up to and including version 2.4.25 (and newer 2.4 series, I believe, since this is a stable series) does not support this, and we did not succeed to build OpenLDAP with NSS support proper. GnuTLS, as a replacement for NSS, adds another layer of complication to the matter. Aside from the TPM user PIN, it requires the higher level software to locate the correct client certificate for the connection to be established inside the TPM (or a software emulation thereof) via so-called "PKCS #11 URIs" in an explicit manner. There does not exist an RFC for these URIs, but a draft only, the latest of which [7] expired in September 2012. NSS hides these details, but the OpenLDAP people did not seem to be keen on supporting NSS for transport layer security when we inquired back in 2010 [8]. AFAICT, there has not been a change in that regard so far. My question now (for documenting the status quo) is whether anyone is currently working on getting certificate-based client authentication utilizing a TPM flying in Evolution for OpenLDAP+GnuTLS at present or whether there are any plans to support this use case in the near future. Kind regards, and looking forward to receiving your thoughts on the matter, Christian [0] https://live.gnome.org/Evolution/Kolab [1] https://mail.gnome.org/archives/evolution-hackers/2010-July/msg00076.html [2] http://sourceforge.net/projects/evolution-kolab/files/Usage_of_software_security_devices_for_client_authentication.pdf/download [3] http://sourceforge.net/projects/opencryptoki/ [4] http://trousers.sourceforge.net/ [5] http://www.openldap.org/ [6] http://www.gnu.org/software/gnutls/gnutls.html [7] https://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 [8] http://www.openldap.org/lists/openldap-technical/201009/msg00350.html -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
