Re: [Evolution-hackers] Evo/E-D-S security (libs) long-term plans

2011-09-13 Thread Christian Hilberg
Hi Milan,

Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha:
 On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote:
We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS.
  
  These are protocols handled by Camel and the underlying NSS library. In
  order to access the crypto token, we needed to supply a token PIN, which
  we were not able to pass from Evo to E-D-S in version 2.30 as live
  data (pass-and- forget). So we had to use a fake implementation: we
  store the user PIN along the rest of the account data and reading it in
  the backend via ESource. Clearly, this violates security (and we are
  saying to in our user manual), but it demonstrates that in principle,
  things are working. To get this thing right, we would need a means to
  ask for a security pin from within the backend, presenting a dialog to
  the user
 
   Hi,
 with the current eds (upcoming 3.2.0) you can pass parameters via
 ECredentials, same as you do with e_passwords_ask_password, thus yes,
 this is doable from book/cal backends now too.

Hum, is ECredentials something a backend can actively request? With NSS, we 
need to register an NSS callback function in our backend, which is called by 
NSS when NSS tries to open the token for the first time in the session. Since 
the token PIN should not be stored anywhere (and removed from memory once the 
token is opened), the callback function will be the one triggering a user 
dialog to be opened, the PIN entered, passed to the callback function and set 
in NSS. After that, the whole dialog stuff will be closed and gone. At least, 
that would be the right way of doing it. It's not a hard requirement for us 
now (politics have changed a little), but there may be similar requirements 
coming from other backends, so I thought of bringing this issue up. And if we 
get the functionality for little money, we can make use of it.

However, there is one protocol, for which we failed to implement any
  demonstrator for client-certificate-based authentication using a hardware
  crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as
  a protocol implementation, which in turn uses GnuTLS for security
  (version 2.1x  2.12 at that time).
 
 The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to
 NSS as well, at least 2.4.23 seems to use NSS based on their changelog.
 Thus, I would say, when you move to current eds, then you can be pretty
 sure that the used OpenLDAP will be the one with NSS. Or you can add a
 dependency to evolution-kolab on the OpenLDAP which fits you best.

Oops, sorry -- I missed to clarify this better. The LDAP access (for 
addresses) I was talking about is the one implemented in Evo itself, not the 
backend variant. There, we hit the aforementioned problem.
  Maybe the new OpenLDAP with NSS support will enable us to do what we need, 
since Evo already provides infrastructure for requesting security PINs. Thanks 
for the hint!

Kind regards,

Christian

-- 
kernel concepts GbRTel: +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 ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evo/E-D-S security (libs) long-term plans

2011-09-12 Thread Milan Crha
On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote:
   We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. 
 These are protocols handled by Camel and the underlying NSS library. In order 
 to access the crypto token, we needed to supply a token PIN, which we were 
 not 
 able to pass from Evo to E-D-S in version 2.30 as live data (pass-and-
 forget). So we had to use a fake implementation: we store the user PIN along 
 the rest of the account data and reading it in the backend via ESource. 
 Clearly, this violates security (and we are saying to in our user manual), 
 but 
 it demonstrates that in principle, things are working. To get this thing 
 right, we would need a means to ask for a security pin from within the 
 backend, presenting a dialog to the user

Hi,
with the current eds (upcoming 3.2.0) you can pass parameters via
ECredentials, same as you do with e_passwords_ask_password, thus yes,
this is doable from book/cal backends now too.

   However, there is one protocol, for which we failed to implement any 
 demonstrator for client-certificate-based authentication using a hardware 
 crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a 
 protocol implementation, which in turn uses GnuTLS for security (version 2.1x 
  2.12 at that time).

The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to
NSS as well, at least 2.4.23 seems to use NSS based on their changelog.
Thus, I would say, when you move to current eds, then you can be pretty
sure that the used OpenLDAP will be the one with NSS. Or you can add a
dependency to evolution-kolab on the OpenLDAP which fits you best.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers