Good morning mates, Apologies for my very very late response….
Just one question for confirming, in Josh’s third point, when sais : > Level 3: > # This level requires encryption and that the certificate presented by > the peer be signed by a trusted CA It means a CA in CA certificate file OR a public key CA in the “TLS CA Certificate Dir”, isn’t it?. > El 1/10/2015, a las 16:09, Ana Emília M. Arruda <emiliaarr...@gmail.com> > escribió: > > 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 so much :) :) to all of you mates, you have helped me tons of it :) :) :) really :) :) > Thank you very much Josh. > > Best regards, > Ana > > > > On Wed, Sep 30, 2015 at 11:22 AM, Josh Fisher <jfis...@pvct.com > <mailto: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 >>> <mailto:emiliaarr...@gmail.com>> escribió: >>> >>> >>> On Mon, Sep 28, 2015 at 6:20 PM, Egoitz Aurrekoetxea < >>> <mailto:ego...@ramattack.net>ego...@ramattack.net >>> <mailto: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 > <http://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 <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > <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
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
