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

[Egoitz Aurrekoetxea]

Thank you so much to all of you :) :)


> El 2 oct 2015, a las 12:54, Josh Fisher  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 >> > 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 > 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 
> > 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 

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

[Egoitz Aurrekoetxea]

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

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

[Josh Fisher]

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 
> 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 > 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
> 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!

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

[Ana Emília M . Arruda]

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

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

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

[Ana Emília M . Arruda]

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 :)​


>
> 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?


>
>
> 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.


>
> If TLS Allowed CN is enabled, then in addition to the peer´s hostname
> being verified, just that ones listed in the "TLS Allowed CN" directives
> are permited.
>
>
> So each part to have it’s proper cert (matching cn with the connecting
> name and so) and if this last is ok… to be in tls allowed cn too… do you
> mean this?
>

Yes, but I misunderstood here. I was having a look into the code and now I
understand this: if TLS Allowed CN is specified, then the CN's listed here
will be verified against ​​the cn present in the certifcate provided by the
peer. If no TLS Allowed CN is specified then a simple host and certificate
common name comparision takes place.


>
> If TLS Verify Peer is not enabled and a client uses a "false" certificate
> (myclient2 using the myclient1 certificate and myclient1 is in the allowed
> CN list, for example) from a host in the allowed CN list of allowed hosts,
> it will work.
>
>
> I see… so the cert can be both from the same ca or not..or… isn’t it?
>
>
> Openssl functions are used for certificate manipulation (including
> validation and verification).
>
>
> Yep I’ve seen in the code…
>
>
> So, it will depend of what you want to have in you TLS communication, even
> if using your own CA for the PKI infrastructure used in your bacula TLS
> environment. You can have your own CA (a virtual machine for this purpose),
> that will be your trusted CA for your environment. And let all your daemons
> trust in each other by setting properly the TLS Verify Peer and TLS Allowed
> CN directives. I think this should work fine for what you want.
>
>
> I could use tls verify peer in the director and in bacula-fd (dir and sd
> are the same machine and to use loopback)…
>
> I wanted each director and each fd, to only be able to be accesed by just
> those remote daemons who own a certificate allowing them to do so…
>
> could you please paste an example config?
>

​Sure. For example, this worked fine for me:

bconsole.conf:

Director {
  Name = director.example.com-dir
  DIRport = 9101
  address 

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

[Egoitz Aurrekoetxea]

Have been taking a look to all this in the source code…

It seems that TLS Verify Peer basically ends up by doing (look at bold please) :

/*
 * Create a new TLS_CONTEXT instance.
 *  Returns: Pointer to TLS_CONTEXT instance on success
 *   NULL on failure;
 */
TLS_CONTEXT *new_tls_context(const char *ca_certfile, const char *ca_certdir,
 const char *certfile, const char *keyfile,
 CRYPTO_PEM_PASSWD_CB *pem_callback,
 const void *pem_userdata, const char *dhfile,
 bool verify_peer)
{
   TLS_CONTEXT *ctx;
   BIO *bio;
   DH *dh;

  .
.
.
.
.
.
.
   SSL_CTX_set_default_passwd_cb(ctx->openssl, tls_pem_callback_dispatch);
   SSL_CTX_set_default_passwd_cb_userdata(ctx->openssl, (void *) ctx);

   /*
* Set certificate verification paths. This requires that at least one
* value be non-NULL
*/
   if (ca_certfile || ca_certdir) {
  if (!SSL_CTX_load_verify_locations(ctx->openssl, ca_certfile, 
ca_certdir)) {
 openssl_post_errors(M_FATAL, _("Error loading certificate verification 
stores"));
 goto err;
  }
   } else if (verify_peer) {
  /* At least one CA is required for peer verification */
  Jmsg0(NULL, M_ERROR, 0, _("Either a certificate file or a directory must 
be"
 " specified as a verification store\n"));
  goto err;
   }

For later but in the same function to : 

   /* Verify Peer Certificate */
   if (verify_peer) {
  /* SSL_VERIFY_FAIL_IF_NO_PEER_CERT has no effect in client mode */
  SSL_CTX_set_verify(ctx->openssl,
 SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
 openssl_verify_peer);
   }

 
It needs a ca public key or a directory with ca public keys….

So I assume that setting properly : 

TLS Enable = Yes
TLS Require = Yes
TLS Certificate =
TLS Key =
TLS Verify Peer =
TLS CA Certificate File = 

it’s enough when you have created all certs with an own (not popularly accepted 
as trusted CA).

The TLS Allowed CN directive, I think it’s just when you use a not dedicated CA 
for the backup or you are using 
a trusted CA where lots of certs could be easily signed (like Thawte) for 
restricting which CN can connect for avoiding 
not authorized valid certs to connect.

And by the way, I think perhaps TLS Verify Peer is not properly documented 
because in : 

http://www.bacula.org/5.1.x-manuals/en/main/main/Bacula_TLS_Communications.html 

 it sais : 

TLS Verify Peer = yes|no
Verify peer certificate. Instructs server to request and verify the client's 
x509 certificate. Any client certificate signed by a known-CA will be accepted 
unless the TLS Allowed CN configuration directive is used, in which case the 
client certificate must correspond to the Allowed Common Name specified. This 
directive is valid only for a server and not in a client context.


But in the code, you can see : 

   /* Verify Peer Certificate */
   if (verify_peer) {
  /* SSL_VERIFY_FAIL_IF_NO_PEER_CERT has no effect in client mode */
  SSL_CTX_set_verify(ctx->openssl,
 SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
 openssl_verify_peer);
   }


both flags and I have seen you call to new_tls_context from filed.c.

Perhaps this should be corrected in the doc? or am I missing something?.

Best regards,



> El 28/9/2015, a las 15:57, Egoitz Aurrekoetxea  
> escribió:
> 
> Hi mates,
> 
> Have been doing some checks with Bacula and TLS. 
> 
> At present I have a TLS enable directive, require tis to yes and the ca 
> certificate public key (of an own CA) copied in the server and the client.
> 
> Now I become an attacker and If I create a new client certificate with the 
> same CN as the present used one in bacula-fd and configure bacula-fd to use 
> this falsified certificate 
> of the falsified ca whose public key is used in the ca cert file directive of 
> the bacula-fd, you can’t do from the server (director) a status client. This 
> seems to be fine, because it seems 
> that like we are not using a known ca (like geotrust, thawte or similar) and 
> each other part is not using certificate signed by the ca whose public key 
> they have in the config each 
> part, the fd and the dir refuse to agree, basically to arrange a TLS 
> connection.
> 
> So now… my question is then… when is required to use TLS Verify peer in the 
> director and the fd?. When someone could use a certificate from Thawte for 
> example??. Then you can use 
> TLS Allowed CN for even in this situation to avoid using this Thawte’s certs 
> in some way?. But how? the CN could be same as the “good” certificate one.
> 
> What’s the real purpose of verify peer an tls allowed cn?.
> 
> Now by the way… the main reason I needed TLS to work fine, is just for 
> avoiding an 

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

[Egoitz Aurrekoetxea]

Good night,

First of all thanks a lot for your time :)

> 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...

> 
> 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 TLS Allowed CN is enabled, then in addition to the peer´s hostname being 
> verified, just that ones listed in the "TLS Allowed CN" directives are 
> permited.

So each part to have it’s proper cert (matching cn with the connecting name and 
so) and if this last is ok… to be in tls allowed cn too… do you mean this?

> If TLS Verify Peer is not enabled and a client uses a "false" certificate 
> (myclient2 using the myclient1 certificate and myclient1 is in the allowed CN 
> list, for example) from a host in the allowed CN list of allowed hosts, it 
> will work.

I see… so the cert can be both from the same ca or not..or… isn’t it?

> 
> Openssl functions are used for certificate manipulation (including validation 
> and verification).

Yep I’ve seen in the code…

> 
> So, it will depend of what you want to have in you TLS communication, even if 
> using your own CA for the PKI infrastructure used in your bacula TLS 
> environment. You can have your own CA (a virtual machine for this purpose), 
> that will be your trusted CA for your environment. And let all your daemons 
> trust in each other by setting properly the TLS Verify Peer and TLS Allowed 
> CN directives. I think this should work fine for what you want.
> 

I could use tls verify peer in the director and in bacula-fd (dir and sd are 
the same machine and to use loopback)…

I wanted each director and each fd, to only be able to be accesed by just those 
remote daemons who own a certificate allowing them to do so…

could you please paste an example config?

> Best regards,

Thank you so much again, really,
Egoitz

> Ana
> 
> 
> On Mon, Sep 28, 2015 at 3:03 PM, Egoitz Aurrekoetxea  > wrote:
> Have been taking a look to all this in the source code…
> 
> It seems that TLS Verify Peer basically ends up by doing (look at bold 
> please) :
> 
> /*
>  * Create a new TLS_CONTEXT instance.
>  *  Returns: Pointer to TLS_CONTEXT instance on success
>  *   NULL on failure;
>  */
> TLS_CONTEXT *new_tls_context(const char *ca_certfile, const char *ca_certdir,
>  const char *certfile, const char *keyfile,
>  CRYPTO_PEM_PASSWD_CB *pem_callback,
>  const void *pem_userdata, const char *dhfile,
>  bool verify_peer)
> {
>TLS_CONTEXT *ctx;
>BIO *bio;
>DH *dh;
> 
>   .
> .
> .
> .
> .
> .
> .
>SSL_CTX_set_default_passwd_cb(ctx->openssl, tls_pem_callback_dispatch);
>SSL_CTX_set_default_passwd_cb_userdata(ctx->openssl, (void *) ctx);
> 
>/*
> * Set certificate verification paths. This requires that at least one
> * value be non-NULL
> */
>if (ca_certfile || 

[Bacula-users] Question about bacula and tls

[Egoitz Aurrekoetxea]

Hi mates,

Have been doing some checks with Bacula and TLS. 

At present I have a TLS enable directive, require tis to yes and the ca 
certificate public key (of an own CA) copied in the server and the client.

Now I become an attacker and If I create a new client certificate with the same 
CN as the present used one in bacula-fd and configure bacula-fd to use this 
falsified certificate 
of the falsified ca whose public key is used in the ca cert file directive of 
the bacula-fd, you can’t do from the server (director) a status client. This 
seems to be fine, because it seems 
that like we are not using a known ca (like geotrust, thawte or similar) and 
each other part is not using certificate signed by the ca whose public key they 
have in the config each 
part, the fd and the dir refuse to agree, basically to arrange a TLS connection.

So now… my question is then… when is required to use TLS Verify peer in the 
director and the fd?. When someone could use a certificate from Thawte for 
example??. Then you can use 
TLS Allowed CN for even in this situation to avoid using this Thawte’s certs in 
some way?. But how? the CN could be same as the “good” certificate one.

What’s the real purpose of verify peer an tls allowed cn?.

Now by the way… the main reason I needed TLS to work fine, is just for avoiding 
an arp poissoning attack to make Bacula store or restore injected data in a 
backup. How could this be done 
noticing that anyone could create a Thawte’s for instance certificate for the 
client, and even you have TLS Allowed CN the CN of the client, as the cert is 
valid, this damage could be caused? 
isn’t it?.

Thanks a lot really,


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

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

[Ana Emília M . Arruda]

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.

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.

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.

If TLS Allowed CN is enabled, then in addition to the peer´s hostname being
verified, just that ones listed in the "TLS Allowed CN" directives are
permited. If TLS Verify Peer is not enabled and a client uses a "false"
certificate (myclient2 using the myclient1 certificate and myclient1 is in
the allowed CN list, for example) from a host in the allowed CN list of
allowed hosts, it will work.

Openssl functions are used for certificate manipulation (including
validation and verification).

So, it will depend of what you want to have in you TLS communication, even
if using your own CA for the PKI infrastructure used in your bacula TLS
environment. You can have your own CA (a virtual machine for this purpose),
that will be your trusted CA for your environment. And let all your daemons
trust in each other by setting properly the TLS Verify Peer and TLS Allowed
CN directives. I think this should work fine for what you want.

Best regards,
Ana


On Mon, Sep 28, 2015 at 3:03 PM, Egoitz Aurrekoetxea 
wrote:

> Have been taking a look to all this in the source code…
>
> It seems that TLS Verify Peer basically ends up by doing (look at bold
> please) :
>
> /*
>  * Create a new TLS_CONTEXT instance.
>  *  Returns: Pointer to TLS_CONTEXT instance on success
>  *   NULL on failure;
>  */
> TLS_CONTEXT *new_tls_context(const char *ca_certfile, const char
> *ca_certdir,
>  const char *certfile, const char *keyfile,
>  CRYPTO_PEM_PASSWD_CB *pem_callback,
>  const void *pem_userdata, const char *dhfile,
>  bool verify_peer)
> {
>TLS_CONTEXT *ctx;
>BIO *bio;
>DH *dh;
>
>   .
> .
> .
> .
> .
> .
> .
>SSL_CTX_set_default_passwd_cb(ctx->openssl, tls_pem_callback_dispatch);
>SSL_CTX_set_default_passwd_cb_userdata(ctx->openssl, (void *) ctx);
>
>/*
> * Set certificate verification paths. This requires that at least one
> * value be non-NULL
> */
> *   if (ca_certfile || ca_certdir) {*
> *  if (!SSL_CTX_load_verify_locations(ctx->openssl, ca_certfile,
> ca_certdir)) {*
> * openssl_post_errors(M_FATAL, _("Error loading certificate
> verification stores"));*
> * goto err;*
> *  }*
> *   } else if (verify_peer) {*
> *  /* At least one CA is required for peer verification */*
> *  Jmsg0(NULL, M_ERROR, 0, _("Either a certificate file or a directory
> must be"*
> * " specified as a verification store\n"));*
> *  goto err;*
> *   }*
>
> For later but in the same function to :
>
>
> *   /* Verify Peer Certificate */   if (verify_peer) {  /*
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT has no effect in client mode */
> SSL_CTX_set_verify(ctx->openssl,
>  SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
>  openssl_verify_peer);   }*
>
> It needs a ca public key or a directory with ca public keys….
>
> So I assume that setting properly :
>
> TLS Enable = Yes
> TLS Require = Yes
> TLS Certificate =
> TLS Key =
> TLS Verify Peer =
> TLS CA Certificate File =
>
> it’s enough when you have created all certs with an own (not popularly
> accepted as trusted CA).
>
> The TLS Allowed CN directive, I think it’s just when you use a not
> dedicated CA for the backup or you are using
> a trusted CA where lots of certs could be easily signed (like Thawte) for
> restricting which CN can connect for avoiding
> not authorized valid certs to connect.
>
> And by the way, I think perhaps TLS Verify Peer is not properly documented
> because in :
>
> *http://www.bacula.org/5.1.x-manuals/en/main/main/Bacula_TLS_Communications.html
> 
>  *it
> sais :
>
> *TLS Verify Peer = yes|no* Verify peer certificate. Instructs server to
> request and verify the client's x509 certificate. Any client certificate
> signed by a known-CA will be