On Fri, Mar 26, 2010 at 12:09 PM, Tyler Gates <tgates81(a)gmail.com> wrote:
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
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
you cannot guarantee the recipient is the only person able to 'see' the