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 The Bacula encryption code was written by Landon Fuller.
18 Supported features of this code include:
20 \item Client/Server TLS Requirement Negotiation
21 \item TLSv1 Connections with Server and Client Certificate
23 \item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
26 This document will refer to both "server" and "client" contexts. These
27 terms refer to the accepting and initiating peer, respectively.
29 Diffie-Hellman anonymous ciphers are not supported by this code. The
30 use of DH anonymous ciphers increases the code complexity and places
31 explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is
32 subject to known plaintext attacks, and it should be considered
33 considerably less secure than PKI certificate-based authentication.
35 Appropriate autoconf macros have been added to detect and use OpenSSL
36 if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
38 \subsection*{TLS Configuration Directives}
39 \addcontentsline{toc}{section}{TLS Configuration Directives}
40 Additional configuration directives have been added to all the daemons
41 (Director, File daemon, and Storage daemon) as well as the various
42 different Console programs.
43 These new directives are defined as follows:
46 \item [TLS Enable = \lt{}yes|no\gt{}]
49 \item [TLS Require = \lt{}yes|no\gt{}]
50 Require TLS connections.
52 \item [TLS Certificate = \lt{}Directory\gt{}]
53 Path to a PEM encoded TLS certificate. It can be used as either a client
54 or server certificate. PEM stands for Privacy Enhanced Mail, but in
55 this context refers to how the certificates are encoded. It is used
56 because PEM files are base64 encoded and hence ASCII text based
57 rather than binary. They may also contain encrypted information.
59 \item [TLS Key = \lt{}Directory\gt{}]
60 Path to a PEM encoded TLS private key. It must correspond to the TLS
63 \item [TLS Verify Peer = \lt{}yes|no\gt{}]
64 Verify peer certificate. Instructs server to request and verify the
65 client's x509 certificate. Any client certificate signed by a known-CA
66 will be accepted unless the TLS Allowed CN configuration directive is used,
67 in which case the client certificate must correspond to the Allowed
68 Common Name specified. This directive is valid only for a server
69 and not in a client context.
71 \item [TLS Allowed CN = \lt{}string list\gt{}]
72 Common name attribute of allowed peer certificates. If this directive is
73 specified, all client certificates will be verified against this list.
74 This directive may be specified more than once. It is not valid in a client
77 \item [TLS CA Certificate File = \lt{}Filename\gt{}]
78 The full path and filename specifying a
79 PEM encoded TLS CA certificate(s). Multiple certificates are
80 permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
81 CA Certificate Dir} are required in a server context if \emph{TLS
82 Verify Peer} (see above) is also specified, and are always required in a client
85 \item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
86 Full path to TLS CA certificate directory. In the current implementation,
87 certificates must be stored PEM encoded with OpenSSL-compatible hashes,
88 which is the subject name's hash and an extension of {bf .0}.
89 One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
90 required in a server context if \emph{TLS Verify Peer} is also specified,
91 and are always required in a client context.
93 \item [TLS DH File = \lt{}Directory\gt{}]
94 Path to PEM encoded Diffie-Hellman parameter file. If this directive is
95 specified, DH key exchange will be used for the ephemeral keying, allowing
96 for forward secrecy of communications. DH key exchange adds an additional
97 level of security because the key used for encryption/decryption by the
98 server and the client is computed on each end and thus is never passed over
99 the network if Diffie-Hellman key exchange is used. Even if DH key
100 exchange is not used, the encryption/decryption key is always passed
101 encrypted. This directive is only valid within a server context.
103 To generate the parameter file, you
107 openssl dhparam -out dh1024.pem -5 1024
112 \subsection*{Creating a Self-signed Certificate}
113 \index[general]{Creating a Self-signed Certificate }
114 \index[general]{Certificate!Creating a Self-signed }
115 \addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
117 You may create a self-signed certificate for use with the Bacula TLS that
118 will permit you to make it function, but will not allow certificate
119 validation. The .pem file containing both the certificate and the key
120 valid for 10 years can be made with the following:
124 openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
128 The above script will ask you a number of questions. You may simply answer
129 each of them by entering a return, or if you wish you may enter your own data.
131 Note, however, that self-signed certificates will only work for the
132 outgoing end of connections. For example, in the case of the Director
133 making a connection to a File Daemon, the File Daemon may be configured to
134 allow self-signed certifictes, but the certificate being sed by the
135 Director must be signed by a certificate that is explicitly trusted on the
138 This is neccessary to prevent ``man in the middle'' attacks from tools such
139 as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
140 Director does not verify that it is talking to a trusted remote endpoint,
141 it can be tricked into talking to a malicious 3rd party who is relaying and
142 capturing all traffic by presenting its own certificates to the Director
143 and File Daemons. The only way to prevent this is by using trusted
144 certificates, so that the man in the middle is incapable of spoofing the
145 connection using his own.
147 To get a trusted certificate (CA or Certificate Authority signed
148 certificate), you will either need to purchase certificates signed by a
149 commercial CA or find a friend that has setup his own CA or become a CA
150 yourself, and thus you can sign all your own certificates. The book
151 OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly explains
152 how to do it, or you can read the documentation provided in the Open-source
153 PKI Book project at Source Forge: \elink{
154 http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
155 {http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
156 Note, this link may change.
158 The program TinyCA has a very nice Graphical User Interface
159 that allows you to easily setup and maintain your own CA.
160 TinyCA can be found at
161 \elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
164 \subsection*{Getting a CA Signed Certificate}
165 \index[general]{Certificate!Getting a CA Signed }
166 \index[general]{Getting a CA Signed Certificate }
167 \addcontentsline{toc}{subsection}{Getting a CA Signed Certificate}
169 The process of getting a certificate that is signed by a CA is quite a bit
170 more complicated. You can purchase one from quite a number of PKI vendors, but
171 that is not at all necessary for use with Bacula. To get a CA signed
172 certificate, you will either need to find a friend that has setup his own CA
173 or to become a CA yourself, and thus you can sign all your own certificates.
174 The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
175 explains how to do it, or you can read the documentation provided in the
176 Open-source PKI Book project at Source Forge:
178 http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
179 {http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
180 Note, this link may change.
182 \subsection*{Example TLS Configuration Files}
183 \index[general]{Example!TLS Configuration Files}
184 \index[general]{TLS Configuration Files}
185 \addcontentsline{toc}{subsection}{Example TLS Configuration Files}
187 Landon has supplied us with the TLS portions of his configuration
188 files, which should help you setting up your own.
190 {\bf bacula-dir.conf}
193 Director { # define myself
198 TLS Verify Peer = yes
199 TLS Allowed CN = "bacula@backup1.example.com"
200 TLS Allowed CN = "administrator@example.com"
201 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
202 # This is a server certificate, used for incoming
203 # console connections.
204 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
205 TLS Key = /usr/local/etc/ssl/backup1/key.pem
210 Address = backup1.example.com
213 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
214 # This is a client certificate, used by the director to
215 # connect to the storage daemon
216 TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
217 TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
230 TLS Verify Peer = yes
231 # Allow only the Director to connect
232 TLS Allowed CN = "bacula@backup1.example.com"
233 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
234 # This is a server certificate. It is used by connecting
235 # directors to verify the authenticity of this file daemon
236 TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
237 TLS Key = /usr/local/etc/ssl/server1/key.pem
245 Storage { # definition of myself
248 # These TLS configuration options are used for incoming
249 # file daemon connections. Director TLS settings are handled
253 # Peer certificate is not required/requested -- peer validity
254 # is verified by the storage connection cookie provided to the
255 # File Daemon by the director.
257 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
258 # This is a server certificate. It is used by connecting
259 # file daemons to verify the authenticity of this storage daemon
260 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
261 TLS Key = /usr/local/etc/ssl/backup1/key.pem
265 # List Directors who are permitted to contact Storage daemon
272 # Require the connecting director to provide a certificate
273 # with the matching CN.
274 TLS Verify Peer = yes
275 TLS Allowed CN = "bacula@backup1.example.com"
276 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
277 # This is a server certificate. It is used by the connecting
278 # director to verify the authenticity of this storage daemon
279 TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
280 TLS Key = /usr/local/etc/ssl/backup1/key.pem