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] is 7.2 ready for prime time?

[Uwe Schuerkamp]

On Fri, Sep 25, 2015 at 09:01:29AM -0700, Stephen Thompson wrote:
> 
> 
> 
> I run daily backups of my database and had finished my monthly full run 
> for September, so I was technically covered.  However I was not looking 
> forward to restoring a 900+Gb mysql database from a text dump which on 
> my system would take days, if not an entire week.  The last time I had 
> to restore database from backup it was 4 or so years ago and my database 
> was only 300-400Gb back then.
> 
> Stephen
> 
> 

One word: innobackupex. You'll be up running in a few minutes again as
opposed to a week when using a text file created by mysqldump (which,
much like MyISAM tables, should be taken round the back and taken out
of its misery once and for all ;))

All the best,

Uwe








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

[Bacula-users] Question about verify job expirations

[Egoitz Aurrekoetxea]

Hi mates,

The first question I have is : 

- Sometime ago, I asked here if the verification init catalog jobs could 
expire, in order to need a new init catalog for new verify catalogs to run. 
Have found in some of my tests that even 
have just than once the init catalog and run daily a verify catalog… this task 
works fine even when having the following retentions : 

- File retention : 21 days
- Job retention : 23 days
- Volume retention : 27 days

I can easily be at the day 60 and still being able to do verify catalogs 
without a new init catalog… could anyone give me please an idea of what could 
be happening?.

Thank you much,
--
___
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