Jorj Bauer wrote: > I didn't actually craft this patch to address any TLS weakness; I wrote > it to address a feature flaw/conflict. > > Let's take the DNS security issue off the table for the moment. > As I mentioned at some point, that's mostly paranoia. As you say, you'd > have to compromise both DNS and one of the root CAs to exploit it. I > only mentioned it for those that are totally paranoid about securing > their clients. (I'm sure they're out there.) >
Bacula does its normal HMAC-MD5 password authentication before starting TLS. It would also be necessary for an attacker to have the FD password, in which case either the FD or the Dir has already been compromised. > >> This is the standard x509 model, used to secure all SSL sites -- >> > > ... when verifying the server's identity from the point of view of the > client. It's also assumed that the server, upon changing its name, will > also change its certificate. This is a valid assumption because servers > are essentially public resources that have to be advertised. > > >> If you do not trust the CAs listed in your CA bundle to correctly >> issue certificates, then you can't trust "www.hsbc.com" to be HSBC >> Bank, either. >> > > This is only true from the client to the server in the TLS model (in > Bacula's case, the Director can validate that the FD is what it thinks > it should be). It does not offer protection in the opposite direction by > default. > > Bacula has an option for any server process to validate arbitrary data > in the corresponding client's CN to try and accomodate the reverse (as > I'm sure you're aware, you probably wrote it). > > >> I don't understand your failure case -- the *entire purpose* of a CA >> is to sign certificates by validating the requesting party. >> > > Okay. Let's look at two features in Bacula. This gets to the heart of my > original problem. > > (1) TLS. This requires that a FD be at a particular DNS name > (specifically, that the FD certificate's CN is the same as the Address > field in the Director's configuration, and the Address field is used as > the DNS name to look up in order to connect to the FD). > > (2) The Director's "setip" command. This allows a client to change its > Address registered with the Director. > > If one uses (2) to change the address of the client, then (1) will fail. > The only ways to avoid this are to > > (a) issue new certificates every time the address changes; > > or > > (b) decouple validation from the DNS name by making the director more > flexible (i.e. separate the piece of information embedded in the cert > from the one that's used to connect to the client). > > Where (b) can be accomplished in at least two ways. One is to separate > the cert CN from the information used to connect to the client (the CN > contains something other than the hostname, and is manually validated). > The other is analogous: have the director keep a second string for the > address update via setip, and then connect to the alternate string but > validate the original one. > > The latter method doesn't solve a similar problem, though: what if a > device has to change name for a non-technical reason? For example, an > office move in an organization where the DNS names are tied to > geographic location. Using non-DNS information embedded in the > certificate here provides a significantly greater level of flexibility, > and Bacula already (by and large) has the infrastructure to deal with > this. > > That's the patch that we're discussing. > > More discussion is welcome. > > The FD address cannot be part of the certificate (CN or any other field) if roaming FDs are ever to be supported. An arbitrary CN will effectively make TLS used for encryption only, not authentication, albeit the cert will still have to be signed by a trusted CA. There's nothing wrong with that. Most secure websites use TLS in this manner, requiring password auth after TLS is started. The difference here is that Bacula does HMAC-MD5 auth before starting TLS, but it is the same net effect. Your patch (or something similar) is necessary to support roaming clients using TLS. So with this patch the cert can be used regardless of FD address, getting a step closer to support of roaming FDs. But how and when does the "SetIP" console command get sent to the Dir? I see several problems with the SetIP approach. What if Bacula attempts to run the job before the SetIP is issued? What if the SetIP is issued, but before the job is run bacula-dir is restarted or reloaded? For roaming clients that are not on all of the time it is entirely likely that they will only rarely if ever be backed up. The patch allows TLS to work for these clients, but still leaves it a guessing game as to when to run the job. I don't see how roaming FDs are really feasible until client-initiated backups are implemented. Still, separating the FD address from the cert is going to be required in order to support roaming clients. --- Josh > -- Jorj > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
