next up previous contents index
Next: Using stunnel to Encrypt Up: Bacula User's Guide Previous: Disaster Recovery Using Bacula   Contents   Index

Subsections


Bacula TLS

Bacula TLS (Transport Layer Security) is built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh. The Bacula code was written by Landon Fuller.

Supported features of this code include:

This document will refer to both "server" and "client" contexts. These terms refer to the accepting and initiating peer, respectively.

Diffie-Hellman anonymous ciphers are not supported by this code. The use of DH anonymous ciphers increases the code complexity and places explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is subject to known plaintext attacks, and it should be considered considerably less secure than PKI certificate-based authentication.

Appropriate autoconf macros have been added to detect and use OpenSSL if enabled on the ./configure line with --enable-openssl

TLS Configuration Directives

Additional configuration directives have been added to all the daemons (Director, File daemon, and Storage daemon) as well as the various different Console programs. These new directives are defined as follows:

TLS Enable = <yes|no>
Enable TLS support.

TLS Require = <yes|no>
Require TLS connections.

TLS Certificate = <Directory>
Path to a PEM encoded TLS certificate. It can be used as either a client or server certificate. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. It is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.

TLS Key = <Directory>
Path to a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>
Verify peer certificate. Instructs server to request and verify the client's x509 certificate. Any client certificate signed by a known-CA will be accepted unless the TLS Allowed CN configuration directive is used, in which case the client certificate must correspond to the Allowed Common Name specified. This directive is valid only for a server and not in a client context.

TLS Allowed CN = <string list>
Common name attribute of allowed peer certificates. If this directive is specified, all client certificates will be verified against this list. This directive may be specified more than once. It is not valid in a client context.

TLS CA Certificate File = <Filename>
The full path and filename specifying a PEM encoded TLS CA certificate(s). Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context if TLS Verify Peer (see above) is also specified, and are always required in a client context.

TLS CA Certificate Dir = <Directory>
Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name's hash and an extension of bf .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context if TLS Verify Peer is also specified, and are always required in a client context.

TLS DH File = <Directory>
Path to PEM encoded Diffie-Hellman parameter file. If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.

To generate the parameter file, you may use openssl:

 
   openssl dhparam -out dh1024.pem -5 1024

Creating a Self-signed Certificate

You may create a self-signed certificate for use with the Bacula TLS that will permit you to make it function, but will not allow certificate validation. The .pem file containing both the certificate and the key valid for 10 years can be made with the following:

   openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650

The above script will ask you a number of questions. You may simply answer each of them by entering a return, or if you wish you may enter your own data.

Getting a CA Signed Certificate

The process of getting a certificate that is signed by a CA is quite a bit more complicated. You can purchase one from quite a number of PKI vendors, but that is not at all necessary for use with Bacula. To get a CA signed certificate, you will either need to find a friend that has setup his own CA or to become a CA yourself, and thus you can sign all your own certificates. The book OpenSSL by John Viega, Matt Mesier & Pravir Chandra from O'Reilly explains how to do it, or you can read the documentation provided in the Open-source PKI Book project at Source Forge: http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm. Note, this link may change.


next up previous contents index
Next: Using stunnel to Encrypt Up: Bacula User's Guide Previous: Disaster Recovery Using Bacula   Contents   Index
/opkg OpenPKG (management) 2005-08-23