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…
# N.B. Use a fully qualified name here SDPort = 9103 Password = "KD+2iTb9oYpCENNic0I+0Ex57FCOY1ruxxE/0pvsRwEc" Device = FileChgr1 Media Type = File1 Maximum Concurrent Jobs = 10 # run up to 10 jobs a the same time TLS Enable = yes TLS Require = yes TLS CA Certificate File = /opt/bacula/certs/ca.crt TLS Certificate = /opt/bacula/certs/director.example.com.crt TLS Key = /opt/bacula/certs/director.example.com.key }
bacula-fd.conf (for client1):
Director { Name = director.example.com-dir Password = "client
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?.
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?.