2 \section*{Bacula TLS -- Communications Encryption}
4 \index[general]{TLS -- Communications Encryption}
5 \index[general]{Communications Encryption}
6 \index[general]{Encryption!Communications}
7 \index[general]{Encryption!Transport}
8 \index[general]{Transport Encryption}
10 \addcontentsline{toc}{section}{TLS -- Communications Encryption}
12 Bacula TLS (Transport Layer Security) is built-in network
13 encryption code to provide secure network transport similar to
14 that offered by {\bf stunnel} or {\bf ssh}. The data written to
15 Volumes by the Storage daemon is not encrypted by this code.
16 For data encryption, please see the \ilink{Data Encryption
17 Chapter}{DataEncryption} of this manual.
19 The Bacula encryption implementations were written by Landon Fuller.
21 Supported features of this code include:
23 \item Client/Server TLS Requirement Negotiation
24 \item TLSv1 Connections with Server and Client Certificate
26 \item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
29 This document will refer to both "server" and "client" contexts. These
30 terms refer to the accepting and initiating peer, respectively.
32 Diffie-Hellman anonymous ciphers are not supported by this code. The
33 use of DH anonymous ciphers increases the code complexity and places
34 explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is
35 subject to known plaintext attacks, and it should be considered
36 considerably less secure than PKI certificate-based authentication.
38 Appropriate autoconf macros have been added to detect and use OpenSSL
39 if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
41 \subsection*{TLS Configuration Directives}
42 \addcontentsline{toc}{section}{TLS Configuration Directives}
43 Additional configuration directives have been added to all the daemons
44 (Director, File daemon, and Storage daemon) as well as the various
45 different Console programs.
46 These new directives are defined as follows:
49 \item [TLS Enable = \lt{}yes|no\gt{}]
50 Enable TLS support. If TLS is not enabled, none of the other TLS directives
51 have any effect. In other words, even if you set {\bf TLS Require = yes}
52 you need to have TLS enabled or TLS will not be used.
54 \item [TLS Require = \lt{}yes|no\gt{}]
55 Require TLS connections. This directive is ignored unless {\bf TLS Enable}
56 is set to {\bf yes}. If TLS is not required, and TLS is enabled, then
57 Bacula will connect with other daemons either with or without TLS depending
58 on what the other daemon requests. If TLS is enabled and TLS is required,
59 then Bacula will refuse any connection that does not use TLS.
61 \item [TLS Certificate = \lt{}Directory\gt{}]
62 Path to a PEM encoded TLS certificate. It can be used as either a client
63 or server certificate. PEM stands for Privacy Enhanced Mail, but in
64 this context refers to how the certificates are encoded. It is used
65 because PEM files are base64 encoded and hence ASCII text based
66 rather than binary. They may also contain encrypted information.
68 \item [TLS Key = \lt{}Directory\gt{}]
69 Path to a PEM encoded TLS private key. It must correspond to the TLS
72 \item [TLS Verify Peer = \lt{}yes|no\gt{}]
73 Verify peer certificate. Instructs server to request and verify the
74 client's x509 certificate. Any client certificate signed by a known-CA
75 will be accepted unless the TLS Allowed CN configuration directive is used,
76 in which case the client certificate must correspond to the Allowed
77 Common Name specified. This directive is valid only for a server
78 and not in a client context.
80 \item [TLS Allowed CN = \lt{}string list\gt{}]
81 Common name attribute of allowed peer certificates. If this directive is
82 specified, all server certificates will be verified against this list. This
83 can be used to ensure that only the CA-approved Director may connect.
84 This directive may be specified more than once. It is not valid in a client
87 \item [TLS CA Certificate File = \lt{}Filename\gt{}]
88 The full path and filename specifying a
89 PEM encoded TLS CA certificate(s). Multiple certificates are
90 permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
91 CA Certificate Dir} are required in a server context if \emph{TLS
92 Verify Peer} (see above) is also specified, and are always required in a client
95 \item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
96 Full path to TLS CA certificate directory. In the current implementation,
97 certificates must be stored PEM encoded with OpenSSL-compatible hashes,
98 which is the subject name's hash and an extension of {bf .0}.
99 One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
100 required in a server context if \emph{TLS Verify Peer} is also specified,
101 and are always required in a client context.
103 \item [TLS DH File = \lt{}Directory\gt{}]
104 Path to PEM encoded Diffie-Hellman parameter file. If this directive is
105 specified, DH key exchange will be used for the ephemeral keying, allowing
106 for forward secrecy of communications. DH key exchange adds an additional
107 level of security because the key used for encryption/decryption by the
108 server and the client is computed on each end and thus is never passed over
109 the network if Diffie-Hellman key exchange is used. Even if DH key
110 exchange is not used, the encryption/decryption key is always passed
111 encrypted. This directive is only valid within a server context.
113 To generate the parameter file, you
117 openssl dhparam -out dh1024.pem -5 1024
122 \subsection*{Creating a Self-signed Certificate}
123 \index[general]{Creating a Self-signed Certificate }
124 \index[general]{Certificate!Creating a Self-signed }
125 \addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
127 You may create a self-signed certificate for use with the Bacula TLS that
128 will permit you to make it function, but will not allow certificate
129 validation. The .pem file containing both the certificate and the key
130 valid for ten years can be made with the following:
134 openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
138 The above script will ask you a number of questions. You may simply answer
139 each of them by entering a return, or if you wish you may enter your own data.
141 Note, however, that self-signed certificates will only work for the
142 outgoing end of connections. For example, in the case of the Director
143 making a connection to a File Daemon, the File Daemon may be configured to
144 allow self-signed certificates, but the certificate used by the
145 Director must be signed by a certificate that is explicitly trusted on the
148 This is necessary to prevent ``man in the middle'' attacks from tools such
149 as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
150 Director does not verify that it is talking to a trusted remote endpoint,
151 it can be tricked into talking to a malicious 3rd party who is relaying and
152 capturing all traffic by presenting its own certificates to the Director
153 and File Daemons. The only way to prevent this is by using trusted
154 certificates, so that the man in the middle is incapable of spoofing the
155 connection using his own.
157 To get a trusted certificate (CA or Certificate Authority signed
158 certificate), you will either need to purchase certificates signed by a
159 commercial CA or find a friend that has setup his own CA or become a CA
160 yourself, and thus you can sign all your own certificates. The book
161 OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly explains
162 how to do it, or you can read the documentation provided in the Open-source
163 PKI Book project at Source Forge: \elink{
164 http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
165 {http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
166 Note, this link may change.
168 The program TinyCA has a very nice Graphical User Interface
169 that allows you to easily setup and maintain your own CA.
170 TinyCA can be found at
171 \elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
174 \subsection*{Getting a CA Signed Certificate}
175 \index[general]{Certificate!Getting a CA Signed }
176 \index[general]{Getting a CA Signed Certificate }
177 \addcontentsline{toc}{subsection}{Getting a CA Signed Certificate}
179 The process of getting a certificate that is signed by a CA is quite a bit
180 more complicated. You can purchase one from quite a number of PKI vendors, but
181 that is not at all necessary for use with Bacula. To get a CA signed
182 certificate, you will either need to find a friend that has setup his own CA
183 or to become a CA yourself, and thus you can sign all your own certificates.
184 The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
185 explains how to do it, or you can read the documentation provided in the
186 Open-source PKI Book project at Source Forge:
188 http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
189 {http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
190 Note, this link may change.
192 \subsection*{Example TLS Configuration Files}
193 \index[general]{Example!TLS Configuration Files}
194 \index[general]{TLS Configuration Files}
195 \addcontentsline{toc}{subsection}{Example TLS Configuration Files}
197 Landon has supplied us with the TLS portions of his configuration
198 files, which should help you setting up your own.
200 {\bf bacula-dir.conf}
203 Director { # define myself
208 TLS Verify Peer = yes
209 TLS Allowed CN = "bacula@backup1.example.com"
210 TLS Allowed CN = "administrator@example.com"
211 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
212 # This is a server certificate, used for incoming
213 # console connections.
214 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
215 TLS Key = /usr/local/etc/ssl/backup1/key.pem
220 Address = backup1.example.com
223 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
224 # This is a client certificate, used by the director to
225 # connect to the storage daemon
226 TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
227 TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
240 TLS Verify Peer = yes
241 # Allow only the Director to connect
242 TLS Allowed CN = "bacula@backup1.example.com"
243 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
244 # This is a server certificate. It is used by connecting
245 # directors to verify the authenticity of this file daemon
246 TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
247 TLS Key = /usr/local/etc/ssl/server1/key.pem
255 Storage { # definition of myself
258 # These TLS configuration options are used for incoming
259 # file daemon connections. Director TLS settings are handled
263 # Peer certificate is not required/requested -- peer validity
264 # is verified by the storage connection cookie provided to the
265 # File Daemon by the director.
267 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
268 # This is a server certificate. It is used by connecting
269 # file daemons to verify the authenticity of this storage daemon
270 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
271 TLS Key = /usr/local/etc/ssl/backup1/key.pem
275 # List Directors who are permitted to contact Storage daemon
282 # Require the connecting director to provide a certificate
283 # with the matching CN.
284 TLS Verify Peer = yes
285 TLS Allowed CN = "bacula@backup1.example.com"
286 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
287 # This is a server certificate. It is used by the connecting
288 # director to verify the authenticity of this storage daemon
289 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
290 TLS Key = /usr/local/etc/ssl/backup1/key.pem