[stunnel-users] Stunnel and configuration

[Jan Meijer]

On Tue, 22 Feb 2005, Bohdan Linda wrote:

>> I use the CApath = directory directive for my client certificates.  The 
>> client certificates are pointed to by hashed symlinks.  Also makes it a lot 
>> easier to remove a client certificate if you want to revoke access to your 
>> stunnel for that particular certificate.
>
> In other words, is it safe to use together:
> CAfile=/path/to/my/cacert.pem
> CApath=/path/to/only/clientcerts

Yep; except that I only have the CA-certificate chain in cacert.pem.

> Does not one override other? Do you have your cacert.pem symlinked in your 
> CApath? And lastly as CApath is within chroot, what is the impact if 
> certificates stored in are "stolen" by successfull break-in?

Q: Does not one override other?
A: not that I know of

Q: Do you have your cacert.pem symlinked in your CApath?
A: no

Q: And lastly as CApath is within chroot, what is the impact if
    certificates stored in are "stolen" by successfull break-in?
A: The certificates are *public*.  So a hacker could allow your clients

    access to a client-certificate authenticated service of his/hers own.
    Far more dangerous would be if your server.pem including its
    private key would be stolen.  An attacker could then impersonate your
    service thereby sniffing whatever traffic passes his stunnel.  There
    are a number of ways to take care of this risk:

    -encrypt the private key of your server.pem; without the passphrase
     the key is useless to an attacker.  There are two disadvantages to
     this approach:
     1. no unattended reboots can be done; no automatic startup of your
        stunnel service *and* you have to type in the passphrase each time
        you (re)start the stunnel daemon.  I've done this for about a year
        with an apache+ssl server and got tired of it;
     2. if your chroot is compromised it would not be unlikely the attacker
        installs a sniffer thus voiding the passphrase if you're unlucky
    -buy an HSM module; they're not that expensive anymore and openssl
     should interface with them
    -try to use an USB-PKI token; they're not expensive at all compared to
     the HSM module and it should be possible to get it working; the
     private key will be safely stored in there; an attacker can't just
     copy it; then again; a USB key is more easily removed by a careless
     person.....
    -make sure you will *detect* any breakin in a timely fashion and then
     assume your private key has been compromised;

Jan

-- 
http://www.surfnet.nl/organisatie/jame