Re: [Bacula-users] Question about bacula and tls

[Egoitz A. <eg...@ra...>]

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 <emi...@gm...> 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 <jf...@pv... <mailto:jf...@pv...>> 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 <emi...@gm... <mailto:emi...@gm...>> escribió:
>>> 
>>> 
>>> On Mon, Sep 28, 2015 at 6:20 PM, Egoitz Aurrekoetxea < <mailto:eg...@ra...>eg...@ra... <mailto:eg...@ra...>> 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
> Bac...@li... <mailto:Bac...@li...>
> https://lists.sourceforge.net/lists/listinfo/bacula-users <https://lists.sourceforge.net/lists/listinfo/bacula-users>
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Bacula-users mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacula-users