There's one sure fire way to find out...
Start it up with a syncrepl, then move the private key, and see if it syncs fine both ways.
Wait a day or so, and make a change and see if that synced.
If I had to put a dollar on it, if guess that it doesn't need the key after startup. I could be horribly wrong though - I'm not a dev, just a user of the software.
:)
- chris
Chris Jacobs, Jr. Unix System Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Thu Mar 25 18:44:47 2010 Subject: Re: tls private key
HI
On Fri, Mar 26, 2010 at 12:09 PM, Tyler Gates tgates81@gmail.com wrote:
Alex, encrypting the private key really isn't necessary and I highly doubt it would work for your application nor be worth the hassel. Securing via file permisssions as mentioned previously is really the best way to tackle this. Think of 'other layers of protection' being firewalls, intrusion detection, restricted logins, chroot jails, etc., etc...
yep go those, firewalls, permissions etc.
I am not sure why every one is against me trying to use another layer of protection, just because I permission it as root.root 440, doesn't mean its safe. I could make it safer, but unecrypting the private key, starting slapd and removing the unecrypted file.
Or thing of it another way, my private key could be on a usb key, that i insert into the machine on start up and remove once slapd has started.
I have seen secure machine compromised before, somebody installed cvs forgot to change the cvs userid password, root hack and a remote user had access to the system. Some times people do silly things
on my laptop - I encrypt the fs and the swap space and my gpg key have userid/passwords and my certs have userid password protection, like to do the same for my ldap setup as well :)
I understand the reasons for encrypting and signing packets or information, just asking if slapd needs access to the private key after it has read the file on startup.
Encryption really works best for UDP like transportation like email where you cannot guarantee the recipient is the only person able to 'see' the document ;)
[snip]
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Chris Jacobs wrote:
There's one sure fire way to find out...
Start it up with a syncrepl, then move the private key, and see if it syncs fine both ways.
Wait a day or so, and make a change and see if that synced.
If I had to put a dollar on it, if guess that it doesn't need the key after
startup. I could be horribly wrong though - I'm not a dev, just a user of the software.
It probably depends on which crypto library you built with. I'm pretty sure OpenSSL and GnuTLS cache the PEM credentials in memory. Not sure what MozNSS does. And of course, if you're paranoid, you can build these libraries to use smart tokens and leave the credentials there instead.
:)
- chris
Chris Jacobs, Jr. Unix System Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.orgopenldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org To: openldap-technical@openldap.orgopenldap-technical@openldap.org Sent: Thu Mar 25 18:44:47 2010 Subject: Re: tls private key
HI
On Fri, Mar 26, 2010 at 12:09 PM, Tyler Gatestgates81@gmail.com wrote:
Alex, encrypting the private key really isn't necessary and I highly doubt it would work for your application nor be worth the hassel. Securing via file permisssions as mentioned previously is really the best way to tackle this. Think of 'other layers of protection' being firewalls, intrusion detection, restricted logins, chroot jails, etc., etc...
yep go those, firewalls, permissions etc.
I am not sure why every one is against me trying to use another layer of protection, just because I permission it as root.root 440, doesn't mean its safe. I could make it safer, but unecrypting the private key, starting slapd and removing the unecrypted file.
Or thing of it another way, my private key could be on a usb key, that i insert into the machine on start up and remove once slapd has started.
I have seen secure machine compromised before, somebody installed cvs forgot to change the cvs userid password, root hack and a remote user had access to the system. Some times people do silly things
on my laptop - I encrypt the fs and the swap space and my gpg key have userid/passwords and my certs have userid password protection, like to do the same for my ldap setup as well :)
I understand the reasons for encrypting and signing packets or information, just asking if slapd needs access to the private key after it has read the file on startup.
Encryption really works best for UDP like transportation like email where you cannot guarantee the recipient is the only person able to 'see' the document ;)
[snip]
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
On Fri, Mar 26, 2010 at 3:18 PM, Howard Chu hyc@symas.com wrote:
Chris Jacobs wrote:
There's one sure fire way to find out...
Start it up with a syncrepl, then move the private key, and see if it syncs fine both ways.
Wait a day or so, and make a change and see if that synced.
If I had to put a dollar on it, if guess that it doesn't need the key after
true, but i thought a quick email to the list would have given me a quick yeah or nay..
startup. I could be horribly wrong though - I'm not a dev, just a user of the software.
It probably depends on which crypto library you built with. I'm pretty sure OpenSSL and GnuTLS cache the PEM credentials in memory. Not sure what MozNSS does. And of course, if you're paranoid, you can build these libraries to use smart tokens and leave the credentials there instead.
built with gnutls (debian build)
Thanks
:)
- chris
[snip]
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Alexander Samad -
Chris Jacobs -
Howard Chu