Re: [Bacula-users] [Bacula-devel] Feature request: more flexible TLS cert validation

[Landon Fuller]

On Mar 14, 2007, at 13:41, Jorj Bauer wrote:

Let's take the DNS security issue off the table for the moment.

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.)

As I mentioned at some point, that's mostly paranoia. As you say, you'd

Sure -- this is the point of centralized x509 infrastructure. The best defense is limiting ones exposure by not trusting a wide array of CAs. In an ideal world, we'd have nice PGP-style web of, and levels, of trust.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.

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

the DNS name to look up in order to connect to the FD).

Okay. Let's look at two features in Bacula. This gets to the heart of my field in the Director's configuration, and the Address field is used as

Either the CN, or the subjectAltName. For mobile clients, without dynamic DNS, this isn't really workable.

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.


The only ways to avoid this are to

  (a) issue new certificates every time the address changes;

  or


      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

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

and Bacula already (by and large) has the infrastructure to deal with
this.

If one uses (2) to change the address of the client, then (1) will fail. (b) decouple validation from the DNS name by making the director more flexible (i.e. separate the piece of information embedded in the cert contains something other than the hostname, and is manually validated). certificate here provides a significantly greater level of flexibility,

If Kern doesn't have any objections, I'd like to merge it into HEAD.

-landonf

Supporting arbitrary CN values in Bacula is a cheap and effective way of decoupling TLS authentication from the hostname, and seems reasonable.

PGP.sig
Description: This is a digitally signed message part

-------------------------------------------------------------------------
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