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