Bacula TLS - Communications Encryption

Bacula TLS is built-in network encryption code to provide secure network transfer and mutual authentication similar to that offered by other TLS-enabled services such as web servers (https://) or email (starttls). The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this code. For data encryption, see the PKI options described in Data Encryption chapter.

Note

TLS is now implemented by default.

Supported features of this code include:

Client/Server TLS Requirement Negotiation

TLSv1.3 Connections with Server and Client Certificate Validation

Depending on particular environments and configuration, the Bacula software may fall back to or even support only earlier versions of TLS. We strongly recommend to always use recent software builds.

Forward Secrecy Support via Diffie-Hellman Ephemeral Keying

TLS-PSK is used by default when TLS certificates are not configured.

This document will refer to both “server” and “client” contexts. These terms refer to the accepting and initiating peer, respectively. In addition, each of the three daemons (Director, File daemon, Storage daemon) as well as the user interface programs (bconsole, tray monitor, etc.) use the same TLS configuration directives. When we are speaking of one or all of these daemons/programs, we will generally refer to them as a “component”.

Diffie-Hellman anonymous ciphers are not supported by this code. The use of DH anonymous ciphers increases the code complexity and places explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is subject to known plaintext attacks, and it should be considered less secure than PKI certificate-based authentication.

Appropriate autoconf macros have been added to detect and use OpenSSL if enabled on the ./configure line with –with-openssl; the use of OpenSSL is required for other functionality as well, and it should be included for all builds.

Note

Bacula Enterprise packages are always built with a recent, distribution specific version of OpenSSL and will therefore always support TLS transport encryption.

Stricter security requirements can be met by using FIPS conforming, validated OpenSSL modules.