-\section*{Bacula TLS}
-\label{_ChapterStart61}
-\index[general]{Bacula TLS}
+\chapter{Bacula TLS -- Communications Encryption}
+\label{CommEncryption}
+\index[general]{TLS -- Communications Encryption}
+\index[general]{Communications Encryption}
+\index[general]{Encryption!Communications}
+\index[general]{Encryption!Transport}
+\index[general]{Transport Encryption}
\index[general]{TLS}
-\addcontentsline{toc}{section}{Bacula TLS}
Bacula TLS (Transport Layer Security) is built-in network
encryption code to provide secure network transport similar to
-that offered by {\bf stunnel} or {\bf ssh}. The Bacula code was
-written by Landon Fuller.
+that offered by {\bf stunnel} or {\bf ssh}. The data written to
+Volumes by the Storage daemon is not encrypted by this code.
+For data encryption, please see the \ilink{Data Encryption
+Chapter}{DataEncryption} of this manual.
+
+The Bacula encryption implementations were written by Landon Fuller.
Supported features of this code include:
\begin{itemize}
considerably less secure than PKI certificate-based authentication.
Appropriate autoconf macros have been added to detect and use OpenSSL
-if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
+if enabled on the {\bf ./configure} line with {\bf \verb?--?with-openssl}
-\subsection*{TLS Configuration Directives}
-\addcontentsline{toc}{section}{TLS Configuration Directives}
+\section{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.
\begin{description}
\item [TLS Enable = \lt{}yes|no\gt{}]
-Enable TLS support.
+Enable TLS support. If TLS is not enabled, none of the other TLS directives
+have any effect. In other words, even if you set {\bf TLS Require = yes}
+you need to have TLS enabled or TLS will not be used.
\item [TLS Require = \lt{}yes|no\gt{}]
-Require TLS connections.
+Require TLS connections. This directive is ignored unless {\bf TLS Enable}
+is set to {\bf yes}. If TLS is not required, and TLS is enabled, then
+Bacula will connect with other daemons either with or without TLS depending
+on what the other daemon requests. If TLS is enabled and TLS is required,
+then Bacula will refuse any connection that does not use TLS.
\item [TLS Certificate = \lt{}Directory\gt{}]
Path to a PEM encoded TLS certificate. It can be used as either a client
\item [TLS Allowed CN = \lt{}string list\gt{}]
Common name attribute of allowed peer certificates. If this directive is
-specified, all client certificates will be verified against this list.
+specified, all server certificates will be verified against this list. This
+can be used to ensure that only the CA-approved Director may connect.
This directive may be specified more than once. It is not valid in a client
context.
\end{description}
-\subsection*{Creating a Self-signed Certificate}
+\section{Creating a Self-signed Certificate}
\index[general]{Creating a Self-signed Certificate }
\index[general]{Certificate!Creating a Self-signed }
-\addcontentsline{toc}{subsection}{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:
+valid for ten years can be made with the following:
\footnotesize
\begin{verbatim}
Note, however, that self-signed certificates will only work for the
outgoing end of connections. For example, in the case of the Director
making a connection to a File Daemon, the File Daemon may be configured to
-allow self-signed certifictes, but the certificate being sed by the
+allow self-signed certificates, but the certificate used by the
Director must be signed by a certificate that is explicitly trusted on the
File Daemon end.
-This is neccessary to prevent ``man in the middle'' attacks from tools such
+This is necessary to prevent ``man in the middle'' attacks from tools such
as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
Director does not verify that it is talking to a trusted remote endpoint,
it can be tricked into talking to a malicious 3rd party who is relaying and
\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
-\subsection*{Getting a CA Signed Certificate}
+\section{Getting a CA Signed Certificate}
\index[general]{Certificate!Getting a CA Signed }
\index[general]{Getting a CA Signed Certificate }
-\addcontentsline{toc}{subsection}{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
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
Note, this link may change.
-\subsection*{Example TLS Configuration Files}
+\section{Example TLS Configuration Files}
\index[general]{Example!TLS Configuration Files}
\index[general]{TLS Configuration Files}
-\addcontentsline{toc}{subsection}{Example TLS Configuration Files}
Landon has supplied us with the TLS portions of his configuration
files, which should help you setting up your own.
-
+
{\bf bacula-dir.conf}
\footnotesize
\begin{verbatim}
Director { # define myself
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = "bacula@backup1.example.com"
Director {
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
# Allow only the Director to connect
# These TLS configuration options are used for incoming
# file daemon connections. Director TLS settings are handled
# below.
+ TLS Enable = yes
TLS Require = yes
# Peer certificate is not required/requested -- peer validity
# is verified by the storage connection cookie provided to the
Director {
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
# Require the connecting director to provide a certificate
# with the matching CN.