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.)
> 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.
-- Jorj
pgpSRrCdK5Xrj.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
