-\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}
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.
+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 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 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
+capturing all traffic by presenting its own certificates to the Director
+and File Daemons. The only way to prevent this is by using trusted
+certificates, so that the man in the middle is incapable of spoofing the
+connection using his own.
+
+To get a trusted certificate (CA or Certificate Authority signed
+certificate), you will either need to purchase certificates signed by a
+commercial CA or find a friend that has setup his own CA or 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: \elink{
+http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
+{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
+Note, this link may change.
+
+The program TinyCA has a very nice Graphical User Interface
+that allows you to easily setup and maintain your own CA.
+TinyCA can be found at
+\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.
}
\end{verbatim}
\normalsize
-
-
-
projects / bacula / docs / blobdiff