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{}Filename\gt{}]
60
The full path and filename of a PEM encoded TLS certificate. It can be
61
used as either a client or server certificate. PEM stands for Privacy
62
Enhanced Mail, but in this context refers to how the certificates are
63
encoded. It is used because PEM files are base64 encoded and hence ASCII
64
text based rather than binary. They may also contain encrypted
67
\item [TLS Key = \lt{}Filename\gt{}]
68
The full path and filename of a PEM encoded TLS private key. It must
69
correspond to the TLS certificate.
71
\item [TLS Verify Peer = \lt{}yes|no\gt{}]
72
Verify peer certificate. Instructs server to request and verify the
73
client's x509 certificate. Any client certificate signed by a known-CA
74
will be accepted unless the TLS Allowed CN configuration directive is used,
75
in which case the client certificate must correspond to the Allowed
76
Common Name specified. This directive is valid only for a server
77
and not in a client context.
79
\item [TLS Allowed CN = \lt{}string list\gt{}]
80
Common name attribute of allowed peer certificates. If this directive is
81
specified, all server certificates will be verified against this list. This
82
can be used to ensure that only the CA-approved Director may connect.
83
This directive may be specified more than once.
85
\item [TLS CA Certificate File = \lt{}Filename\gt{}]
86
The full path and filename specifying a
87
PEM encoded TLS CA certificate(s). Multiple certificates are
88
permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
89
CA Certificate Dir} are required in a server context if \emph{TLS
90
Verify Peer} (see above) is also specified, and are always required in a client
93
\item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
94
Full path to TLS CA certificate directory. In the current implementation,
95
certificates must be stored PEM encoded with OpenSSL-compatible hashes,
96
which is the subject name's hash and an extension of {bf .0}.
97
One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
98
required in a server context if \emph{TLS Verify Peer} is also specified,
99
and are always required in a client context.
101
\item [TLS DH File = \lt{}Directory\gt{}]
102
Path to PEM encoded Diffie-Hellman parameter file. If this directive is
103
specified, DH key exchange will be used for the ephemeral keying, allowing
104
for forward secrecy of communications. DH key exchange adds an additional
105
level of security because the key used for encryption/decryption by the
106
server and the client is computed on each end and thus is never passed over
107
the network if Diffie-Hellman key exchange is used. Even if DH key
108
exchange is not used, the encryption/decryption key is always passed
109
encrypted. This directive is only valid within a server context.
111
To generate the parameter file, you
115
openssl dhparam -out dh1024.pem -5 1024
120
\section{Creating a Self-signed Certificate}
121
\index[general]{Creating a Self-signed Certificate }
122
\index[general]{Certificate!Creating a Self-signed }
124
You may create a self-signed certificate for use with the Bacula TLS that
125
will permit you to make it function, but will not allow certificate
126
validation. The .pem file containing both the certificate and the key
127
valid for ten years can be made with the following:
131
openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
135
The above script will ask you a number of questions. You may simply answer
136
each of them by entering a return, or if you wish you may enter your own data.
138
Note, however, that self-signed certificates will only work for the
139
outgoing end of connections. For example, in the case of the Director
140
making a connection to a File Daemon, the File Daemon may be configured to
141
allow self-signed certificates, but the certificate used by the
142
Director must be signed by a certificate that is explicitly trusted on the
145
This is necessary to prevent ``man in the middle'' attacks from tools such
146
as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
147
Director does not verify that it is talking to a trusted remote endpoint,
148
it can be tricked into talking to a malicious 3rd party who is relaying and
149
capturing all traffic by presenting its own certificates to the Director
150
and File Daemons. The only way to prevent this is by using trusted
151
certificates, so that the man in the middle is incapable of spoofing the
152
connection using his own.
154
To get a trusted certificate (CA or Certificate Authority signed
155
certificate), you will either need to purchase certificates signed by a
156
commercial CA or find a friend that has setup his own CA or become a CA
157
yourself, and thus you can sign all your own certificates. The book
158
OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly explains
159
how to do it, or you can read the documentation provided in the Open-source
160
PKI Book project at Source Forge: \elink{
161
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
162
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
163
Note, this link may change.
165
The program TinyCA has a very nice Graphical User Interface
166
that allows you to easily setup and maintain your own CA.
167
TinyCA can be found at
168
\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
171
\section{Getting a CA Signed Certificate}
172
\index[general]{Certificate!Getting a CA Signed }
173
\index[general]{Getting a CA Signed Certificate }
175
The process of getting a certificate that is signed by a CA is quite a bit
176
more complicated. You can purchase one from quite a number of PKI vendors, but
177
that is not at all necessary for use with Bacula. To get a CA signed
178
certificate, you will either need to find a friend that has setup his own CA
179
or to become a CA yourself, and thus you can sign all your own certificates.
180
The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
181
explains how to do it, or you can read the documentation provided in the
182
Open-source PKI Book project at Source Forge:
184
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
185
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
186
Note, this link may change.
188
\section{Example TLS Configuration Files}
189
\index[general]{Example!TLS Configuration Files}
190
\index[general]{TLS Configuration Files}
192
Landon has supplied us with the TLS portions of his configuration
193
files, which should help you setting up your own. Note, this example
194
shows the directives necessary for a Director to Storage daemon session.
195
The technique is the same between the Director and the Client and
196
for bconsole to the Director.
198
{\bf bacula-dir.conf}
201
Director { # define myself
206
TLS Verify Peer = yes
207
TLS Allowed CN = "bacula@backup1.example.com"
208
TLS Allowed CN = "administrator@example.com"
209
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
210
# This is a server certificate, used for incoming
211
# console connections.
212
TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
213
TLS Key = /usr/local/etc/ssl/backup1/key.pem
218
Address = backup1.example.com
221
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
222
# This is a client certificate, used by the director to
223
# connect to the storage daemon
224
TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
225
TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
230
Address = server1.example.com
235
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
249
TLS Verify Peer = yes
250
# Allow only the Director to connect
251
TLS Allowed CN = "bacula@backup1.example.com"
252
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
253
# This is a server certificate. It is used by connecting
254
# directors to verify the authenticity of this file daemon
255
TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
256
TLS Key = /usr/local/etc/ssl/server1/key.pem
262
# you need these TLS entries so the SD and FD can
267
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
268
TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
269
TLS Key = /usr/local/etc/ssl/server1/key.pem
277
Storage { # definition of myself
280
# These TLS configuration options are used for incoming
281
# file daemon connections. Director TLS settings are handled
285
# Peer certificate is not required/requested -- peer validity
286
# is verified by the storage connection cookie provided to the
287
# File Daemon by the director.
289
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
290
# This is a server certificate. It is used by connecting
291
# file daemons to verify the authenticity of this storage daemon
292
TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
293
TLS Key = /usr/local/etc/ssl/backup1/key.pem
297
# List Directors who are permitted to contact Storage daemon
304
# Require the connecting director to provide a certificate
305
# with the matching CN.
306
TLS Verify Peer = yes
307
TLS Allowed CN = "bacula@backup1.example.com"
308
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
309
# This is a server certificate. It is used by the connecting
310
# director to verify the authenticity of this storage daemon
311
TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
312
TLS Key = /usr/local/etc/ssl/backup1/key.pem
added
removed
manuals/es/main/tls.tex
