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 <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<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
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
<mailto: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
