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
<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 <ego...@ramattack.net>
> 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 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
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
