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 > <mailto:ego...@ramattack.net>> 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 <emiliaarr...@gmail.com >> <mailto:emiliaarr...@gmail.com>> 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 <http://myclient2.example.com/> >> cannot be used, for example, by a host named myclient1.example.com >> <http://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 the remote side certificate to be signed by the CA "TLS CA Certificate File” or by a CA whose public key is in "TLS CA Certificate Dir”. Isn’t 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. > > 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. I see so if I’m connecting to, for instance : aaaa.bbb.ccc if "TLS Allowed CN” is not specified it just checks that the name we are connecting to “aaaa.bbb.ccc” is the same as the CN offered by the remote side's certificate. Isn’t it? > > >> 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. > You mean if "TLS Verify Peer” is not enabled one can generate any certificate with any CA and any CN on one side and any of the sides won’t complain? > 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 <http://director.example.com/>-dir > DIRport = 9101 > address = director.example.com <http://director.example.com/> > Password = "bacula-dir" > TLS Enable = yes > TLS Require = yes > TLS Certificate = /opt/bacula/certs/director.example.com.crt > TLS Key = /opt/bacula/certs/director.example.com.key > TLS CA Certificate File = /opt/bacula/certs/ca.crt > } > > bacula-dir.conf: > > Director { # define myself > Name = director.example.com <http://director.example.com/>-dir > DIRport = 9101 > DIRAddress = director.example.com <http://director.example.com/> > QueryFile = "/opt/bacula/etc/query.sql" > WorkingDirectory = "/opt/bacula/working" > PidDirectory = "/opt/bacula/working" > Maximum Concurrent Jobs = 20 > Password = "bacula-dir" > Messages = Daemon > TLS Enable = yes > TLS Require = yes > TLS Verify Peer = yes > TLS Allowed CN = “director.example.com <http://director.example.com/>" Shouldn’t you specify here in "TLS Allowed CN” the names of all the file daemons (with bacula-fd not bconsole) connecting to this dir, for being able them to connect to the dir and do the scheduled jobs and so (backups, verification jobs, restores….). > 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 > } > > Client { > Name = client1.example.com <http://client1.example.com/>-fd > Address = client1.example.com <http://client1.example.com/> > FDPort = 9102 > Catalog = MyCatalog > Password = "client1-fd" > File Retention = 60 days # 60 days > Job Retention = 6 months # six months > AutoPrune = yes # Prune expired Jobs/Files > 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 > } > > Storage { > Name = File1 > Address = director.example.com <http://director.example.com/> > # 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 Verify Peer = Yes This should be important here too as the machines running bacula-fd upload the backup content directly to the sd…. and for avoiding the MITM attacks described before, isn’t it? > 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 <http://director.example.com/>-dir > Password = "client1-fd" > TLS Enable = yes > TLS Require = yes > TLS Verify Peer = yes > TLS Allowed CN = "director.example.com <http://director.example.com/>" > TLS CA Certificate File = /opt/bacula/certs/ca.crt > TLS Certificate = /opt/bacula/certs/client1.example.com.crt > TLS Key = /opt/bacula/certs/client1.example.com.key > } > > Hope someone else can improve this answer with more tests/examples. > Very thankful really Ana, Best regards, > Best regards, > Ana > > > >> Best regards, > > Thank you so much again, really, > Egoitz > >> Ana
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
