Thank you so much to all of you :) :)
> El 2 oct 2015, a las 12:54, Josh Fisher <jfis...@pvct.com> escribió: > > > > On 10/2/2015 2:47 AM, Egoitz Aurrekoetxea wrote: >> 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?. > > Yes. > >> >> >>> El 1/10/2015, a las 16:09, Ana Emília M. Arruda <emiliaarr...@gmail.com >>> <mailto: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 < >>> <mailto:jfis...@pvct.com>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 < >>>>> <mailto:emiliaarr...@gmail.com>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 >>> <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
