Hello Egoitz, Is this thread clear? If you have your own dedicated CA, then take care of her :). This way and having level 4 bacula TLS configured as Josh explained, then your communication will be "secure" (never say that we are 100% secure...).
Thank you very much Josh. Best regards, Ana On Wed, Sep 30, 2015 at 11:22 AM, Josh Fisher <jfis...@pvct.com> wrote: > > > 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 <emiliaarr...@gmail.com> > escribió: > > > On Mon, Sep 28, 2015 at 6:20 PM, Egoitz Aurrekoetxea < > <ego...@ramattack.net>ego...@ramattack.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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > >
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
