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

[Egoitz Aurrekoetxea]

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  
> escribió:
> 
> 
> On Mon, Sep 28, 2015 at 6:20 PM, Egoitz Aurrekoetxea  > wrote:
> Good night,
> 
> ​Good night Egoitz. Sorry for my late reply.​
>  
> 
> First of all thanks a lot for your time :)
> 
> ​Thank you for this thread :)​

Thanks to you always :)

>  
> 
>> El 28/9/2015, a las 21:46, Ana Emília M. Arruda > > escribió:
>> 
>> Hello,
>> 
>> The TLS enable do not force the use of TLS. For example, if you configure 
>> your director with TLS enable = yes and TLS require = no, clients can 
>> communicate with your director with or without TLS. But if you configure 
>> your director with both TLS enable and TLS require = yes, then all your 
>> clients and storage daemons will only be able to communicate with your 
>> director with TLS.
>> 
> 
> Yes, this is clear
> 
> 
>> If you do not set TLS Verify Peer or TLS Allowed CN, then you can use any 
>> Certificate File or Directory. The certificate CN will not be checked 
>> against the Certificate File or Directory configured.
> 
> what do you mean? any ca or ca path for each side cert? I could use 
> certificates from different ca in each side?. Even having the proper cn, this 
> doesn’t worked in my testing env (which doesn’t use tis verify peer or tls 
> allowed cn) … you mean the certificate won’t be checked if it was created by 
> the ca_certificate file's ca? Sorry can’t understand this...
> 
> ​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?.

>  
> 
>> 
>> If TLS Verify Peer is enabled, then the peer´s hostname is verified against 
>> the subjectAltName (alternative name) and commonName attributes. This way, a 
>> certificate issued for myclient2.example.com  
>> cannot be used, for example, by a host named myclient1.example.com 
>> . Even if they are issued by your own CA (not 
>> a trusted root CA), you have the CN of the certificate file checked against 
>> the hostname (director, client or storage daemon host) that is using it.
> 
> Are you sure? this config parameter requires to specify ca cert file or ca 
> path.. and the code seems to be doing a check of the remote side cert to be 
> issued by the ca listed in ca cert or ca path…..
> 
> This just means the tls verify peer?. You can for instance use different ca 
> for bacula-dir and bacula-fd mean while one cert with one ca has as cn the 
> server name and the other one the bacula-fd’s daemon hostname?. Even when the 
> ca is not trusted?? will it work?. Sorry but this doesn’t work to me…. are 
> you really sure Ana?
> 
> 
> ​If you have certificates signed by different CA's, you just need to inform 
> them through the "TLS CA Certificate File" or ​"TLS CA Certificate Dir" to 
> the other peer. For example, if you have director's certificate signed by CA1 
> and you have client1's certificate signed by CA2, then your director will 
> need to know about the CA2 certificate to verify the client1 certificate.

That’s it… so then even if the OS and Openssl comes with root ca certificates 
from known trusted CA (Thawte, Verisign, etc) a certificate signed by these CA 
won’t be accepted by a remote side where the ca certificate and all of 
it’s intermediates is not in a  file in "TLS CA Certificate Dir” or is the own 
file in "TLS CA Certificate File”. I mean even being known in the world and by 
the OS running in the certificate verifying machine, if the CA certs don’t 
exist in 
the "TLS CA Certificate Dir” or is not the "TLS CA Certificate File” won’t 
never be accepted by the certificate verifying part.

So then, "TLS Verify Peer” apart from checking the CN of the cert offered by 
the machine we are connecting to, to be the same as the entire name we have 
asked for resolution for connecting to the other side it checks too that 

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

[Josh Fisher]

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 
> escribió:



On Mon, Sep 28, 2015 at 6:20 PM, Egoitz 
Aurrekoetxea>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