3
\label{_ChapterStart61}
4
\index[general]{Bacula TLS}
6
\addcontentsline{toc}{section}{Bacula TLS}
8
Bacula TLS (Transport Layer Security) is built-in network
9
encryption code to provide secure network transport similar to
10
that offered by {\bf stunnel} or {\bf ssh}. The Bacula code was
11
written by Landon Fuller.
13
Supported features of this code include:
15
\item Client/Server TLS Requirement Negotiation
16
\item TLSv1 Connections with Server and Client Certificate
18
\item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
21
This document will refer to both "server" and "client" contexts. These
22
terms refer to the accepting and initiating peer, respectively.
24
Diffie-Hellman anonymous ciphers are not supported by this code. The
25
use of DH anonymous ciphers increases the code complexity and places
26
explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is
27
subject to known plaintext attacks, and it should be considered
28
considerably less secure than PKI certificate-based authentication.
30
Appropriate autoconf macros have been added to detect and use OpenSSL
31
if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
33
\subsection*{TLS Configuration Directives}
34
\addcontentsline{toc}{section}{TLS Configuration Directives}
35
Additional configuration directives have been added to all the daemons
36
(Director, File daemon, and Storage daemon) as well as the various
37
different Console programs.
38
These new directives are defined as follows:
41
\item [TLS Enable = \lt{}yes|no\gt{}]
44
\item [TLS Require = \lt{}yes|no\gt{}]
45
Require TLS connections.
47
\item [TLS Certificate = \lt{}Directory\gt{}]
48
Path to a PEM encoded TLS certificate. It can be used as either a client
49
or server certificate. PEM stands for Privacy Enhanced Mail, but in
50
this context refers to how the certificates are encoded. It is used
51
because PEM files are base64 encoded and hence ASCII text based
52
rather than binary. They may also contain encrypted information.
54
\item [TLS Key = \lt{}Directory\gt{}]
55
Path to a PEM encoded TLS private key. It must correspond to the TLS
58
\item [TLS Verify Peer = \lt{}yes|no\gt{}]
59
Verify peer certificate. Instructs server to request and verify the
60
client's x509 certificate. Any client certificate signed by a known-CA
61
will be accepted unless the TLS Allowed CN configuration directive is used,
62
in which case the client certificate must correspond to the Allowed
63
Common Name specified. This directive is valid only for a server
64
and not in a client context.
66
\item [TLS Allowed CN = \lt{}string list\gt{}]
67
Common name attribute of allowed peer certificates. If this directive is
68
specified, all client certificates will be verified against this list.
69
This directive may be specified more than once. It is not valid in a client
72
\item [TLS CA Certificate File = \lt{}Filename\gt{}]
73
The full path and filename specifying a
74
PEM encoded TLS CA certificate(s). Multiple certificates are
75
permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
76
CA Certificate Dir} are required in a server context if \emph{TLS
77
Verify Peer} (see above) is also specified, and are always required in a client
80
\item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
81
Full path to TLS CA certificate directory. In the current implementation,
82
certificates must be stored PEM encoded with OpenSSL-compatible hashes,
83
which is the subject name's hash and an extension of {bf .0}.
84
One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
85
required in a server context if \emph{TLS Verify Peer} is also specified,
86
and are always required in a client context.
88
\item [TLS DH File = \lt{}Directory\gt{}]
89
Path to PEM encoded Diffie-Hellman parameter file. If this directive is
90
specified, DH key exchange will be used for the ephemeral keying, allowing
91
for forward secrecy of communications. DH key exchange adds an additional
92
level of security because the key used for encryption/decryption by the
93
server and the client is computed on each end and thus is never passed over
94
the network if Diffie-Hellman key exchange is used. Even if DH key
95
exchange is not used, the encryption/decryption key is always passed
96
encrypted. This directive is only valid within a server context.
98
To generate the parameter file, you
102
openssl dhparam -out dh1024.pem -5 1024
107
\subsection*{Creating a Self-signed Certificate}
108
\index[general]{Creating a Self-signed Certificate }
109
\index[general]{Certificate!Creating a Self-signed }
110
\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
112
You may create a self-signed certificate for use with the Bacula TLS that
113
will permit you to make it function, but will not allow certificate
114
validation. The .pem file containing both the certificate and the key
115
valid for 10 years can be made with the following:
119
openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
123
The above script will ask you a number of questions. You may simply answer
124
each of them by entering a return, or if you wish you may enter your own data.
126
Note, however, that self-signed certificates will only work for the
127
outgoing end of connections. For example, in the case of the Director
128
making a connection to a File Daemon, the File Daemon may be configured to
129
allow self-signed certifictes, but the certificate being sed by the
130
Director must be signed by a certificate that is explicitly trusted on the
133
This is neccessary to prevent ``man in the middle'' attacks from tools such
134
as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
135
Director does not verify that it is talking to a trusted remote endpoint,
136
it can be tricked into talking to a malicious 3rd party who is relaying and
137
capturing all traffic by presenting its own certificates to the Director
138
and File Daemons. The only way to prevent this is by using trusted
139
certificates, so that the man in the middle is incapable of spoofing the
140
connection using his own.
142
To get a trusted certificate (CA or Certificate Authority signed
143
certificate), you will either need to purchase certificates signed by a
144
commercial CA or find a friend that has setup his own CA or become a CA
145
yourself, and thus you can sign all your own certificates. The book
146
OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly explains
147
how to do it, or you can read the documentation provided in the Open-source
148
PKI Book project at Source Forge: \elink{
149
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
150
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
151
Note, this link may change.
153
The program TinyCA has a very nice Graphical User Interface
154
that allows you to easily setup and maintain your own CA.
155
TinyCA can be found at
156
\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
159
\subsection*{Getting a CA Signed Certificate}
160
\index[general]{Certificate!Getting a CA Signed }
161
\index[general]{Getting a CA Signed Certificate }
162
\addcontentsline{toc}{subsection}{Getting a CA Signed Certificate}
164
The process of getting a certificate that is signed by a CA is quite a bit
165
more complicated. You can purchase one from quite a number of PKI vendors, but
166
that is not at all necessary for use with Bacula. To get a CA signed
167
certificate, you will either need to find a friend that has setup his own CA
168
or to become a CA yourself, and thus you can sign all your own certificates.
169
The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
170
explains how to do it, or you can read the documentation provided in the
171
Open-source PKI Book project at Source Forge:
173
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
174
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
175
Note, this link may change.
177
\subsection*{Example TLS Configuration Files}
178
\index[general]{Example!TLS Configuration Files}
179
\index[general]{TLS Configuration Files}
180
\addcontentsline{toc}{subsection}{Example TLS Configuration Files}
182
Landon has supplied us with the TLS portions of his configuration
183
files, which should help you setting up your own.
185
{\bf bacula-dir.conf}
188
Director { # define myself
192
TLS Verify Peer = yes
193
TLS Allowed CN = "bacula@backup1.example.com"
194
TLS Allowed CN = "administrator@example.com"
195
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
196
# This is a server certificate, used for incoming
197
# console connections.
198
TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
199
TLS Key = /usr/local/etc/ssl/backup1/key.pem
204
Address = backup1.example.com
207
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
208
# This is a client certificate, used by the director to
209
# connect to the storage daemon
210
TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
211
TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
223
TLS Verify Peer = yes
224
# Allow only the Director to connect
225
TLS Allowed CN = "bacula@backup1.example.com"
226
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
227
# This is a server certificate. It is used by connecting
228
# directors to verify the authenticity of this file daemon
229
TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
230
TLS Key = /usr/local/etc/ssl/server1/key.pem
238
Storage { # definition of myself
241
# These TLS configuration options are used for incoming
242
# file daemon connections. Director TLS settings are handled
245
# Peer certificate is not required/requested -- peer validity
246
# is verified by the storage connection cookie provided to the
247
# File Daemon by the director.
249
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
250
# This is a server certificate. It is used by connecting
251
# file daemons to verify the authenticity of this storage daemon
252
TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
253
TLS Key = /usr/local/etc/ssl/backup1/key.pem
257
# List Directors who are permitted to contact Storage daemon
263
# Require the connecting director to provide a certificate
264
# with the matching CN.
265
TLS Verify Peer = yes
266
TLS Allowed CN = "bacula@backup1.example.com"
267
TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
268
# This is a server certificate. It is used by the connecting
269
# director 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
added
removed
manual-de/tls.tex
