Re: [Bacula-users] Question about bacula and tls
2015-09-30 10:23:55
On 9/30/2015 3:18 AM, Egoitz
Aurrekoetxea wrote:
Hi Ana!!
Really thanks for answering my doubts :)
I do answer in black below...
On
Mon, Sep 28, 2015 at 6:20 PM, Egoitz Aurrekoetxea <egoitz AT ramattack DOT net> wrote:
Good night,
Yes, you can have certificates from
different CA in each side, you just need to inform the
CA correctly for peer verification. How did you
generated your certificates? Do you have a CA and
signed them properly?
I have an own dedicated CA for Bacula systems. One of the
things I was trying to get with TLS is the fact that like
both sides know the CA public key, they to be able to check
if the information received in each side
because of the other side’s sent data in unaltered due to
a possible MITM issue. I mean, could I with verify peer
ensure that if someone tries to do a MITM won’t succeed
because both sides know the CA allowed to
be used in signed certs?. So an attacker doing a signed
certificate with a new CA (CA of the attacker for signing
the attacking used certificate) won’t be able then to inject
content in dir and fd dialogue or fd and sd dialogue?.
Or at least if it does, do each side, the sd, fd or the
dir, interrupt the connection and stop the job notifying?.
Think of it as 5 different security levels.
Level 0:
# Data is transmitted as plain text
TLS Enable = no
Level 1:
# This level allows opportunistic encryption if the peer
chooses, or the peer can communicate in plain text.
TLS Enable = yes
TLS Require = no
TLS Verify Peer = no
TLS Certificate = /etc/bacula/cert.pem
TLS Key = /etc/bacula/key.pem
TLS CA Certificate File = /path/to/system/cafile
Level 2:
# This level requires encryption of data. Any certificate will
do, even a self-signed certificate.
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = no
TLS Certificate = /etc/bacula/cert.pem
TLS Key = /etc/bacula/key.pem
TLS CA Certificate File = /path/to/system/cafile
Level 3:
# This level requires encryption and that the certificate
presented by the peer be signed by a trusted CA
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Certificate = /etc/bacula/cert.pem
TLS Key = /etc/bacula/key.pem
TLS CA Certificate File = /path/to/system/cafile
Level 4:
# This level requires encryption and that the certificate
presented by the peer be signed by a trusted CA
# and that the certificate have a specific CN
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = "some.client.common.name"
TLS Certificate = /etc/bacula/cert.pem
TLS Key = /etc/bacula/key.pem
TLS CA Certificate File = /path/to/system/cafile
As for a MiTM attack, keep in mind that an active attack is harder
than a passive attack. Even opportunistic encryption with
self-signed certs protects against passive snooping. Protecting
against an active MiTM attack requires authentication. Heartbleed
bug aside, level 3 means that the attacker must somehow acquire
certificates signed by a CA in the TLS CA Certificate Files of both
client and server. Level 4 means that she must steal particular
certificates. So level 4 makes a MiTM attack very difficult.
That said, the real danger is a valid certificate that is stolen or
compromised. The CA can revoke a certificate, but this does no good
because, as far as I can tell, Bacula does not check CRLs! Level 3
is not very useful without CRL checks. Therefore, always use level
4, at least until Bacula supports CRL checks, since then a can be
avoided by removing its CN from the TLS Allowed CN list. If you are
not wrorried about MiTM attacks and just want to prevent snooping,
then level 2 will suffice.
|
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
|
|