On 9/30/2015 3:18 AM, Egoitz Aurrekoetxea wrote:

Hi Ana!!

Really thanks for answering my doubts :)

I do answer in black below...

El 30/9/2015, a las 6:24, Ana Emília M. Arruda <emiliaarruda AT gmail DOT com> escribió:

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